Watch the talk linked above. He goes into a lot of the reasons. Security is definitely a big one. Other things seem to be addressing problems that originated from poorly informed decisions early in development that the node.js community has had to deal with ever since (require() based module resolution, npm, etc...).
Node.JS's require, the lexical scoped module system, encourages you to lift out code as modules, rather then "include files". The difference between an "include file" and a "module" is that modules can have dependencies, but can be reused elsewhere. While "include files" depends on the environment where they are included. Now if you have a module that can be reused elsewhere, why not share it to the world!? So instead of copying random pieces of code from here and there, with Node.JS you got an official library repository aka NPM.
You don't really need NPM hosting with Deno. What you need is an index: sources can be hosted elsewhere independently, and instead people can build sites for popular module lookups.
A package manager is different from package hosting. In the case of Deno you can still build and use third party package managers (and they might be able to utilize Deno's import-maps support to achieve some "magic")
We currently support Rust message-passing based plugins. Rust sources can be fetched with Cargo or other alternative tools.
Maybe (just "maybe" for now) we will be able to support plugin imports. In that case dylibs could be directly pulled down from network just like normal files (don't take my words as official though -- we have not decided on that yet)
I wasn’t just thinking about the features themselves, but the big picture. It does seem a bit exploratory to me (weren’t the non-V8 parts written in Go once?)
