No it is not, that it what the esm.sh is for. It transforms a npm package into a ES module. Just make sure that when you have the dependencies A@2 and B@1 where B@1 depends on A@1 (in package.json) then you end up with 3 dependencies A@1, A@2 and B2 which results in bugs if your code expect the versions of A to match. Similar for using the same version of A but a different version of the api like esh.sh/v10/A@1 and esh.sh/v11/B@1 this will result in esh.sh/v10/A@1, esh.sh/v11/A@1 and esh.sh/v11/B@2.
Why does it matter? Deno should not need NPM in any capacity, or does it?
Because npm is the biggest repo in the history of computing and Deno makes it redundant. The people at Jetbrains knew about backwards compatibility when they created Kotlin. It's too late to just ditch npm.
Not quite sure why you shouldn't be able to create a proxy service that serves NPM packages in a form that Deno can consume if you feel the overwhelming need to use NPM packages. (I don't, personally, but tastes differ, I'm sure.)