Another comment [0] provided a list of features differenting Deno vs Node, but once it's complete, in what situations would it be more appropriate to use Deno rather than Node?
The cool stuff I think is in where Deno is different. Able to be used as a library from other Rust or C compatible languages. Able to compile your javascript and Deno itself together into a single binary, etc
2. Management sanity. Deno is written in TypeScript, so it doesn't need something like @types/node to interface with TypeScript the way Node does. This is rarely problematic, but when it does come up its painful. For example in Node the http response type is http.incomingMessage. The port number of the originating server is in there at response.socket.server.port, but @types/node currently thinks response.socket is typed to net.socket which doesn't have a server property and so you get a compile error.
3. Distribution sanity. If you download the @angular/cli framework from NPM it is, at this time, 250 NPM dependencies and 26.6mb for just the CLI interface. The full framework is closer to 90mb and 1140 NPM dependencies. That is insanity. The Node binary plus installer for Windows is only 18.6mb. Deno wants to solve this by wrapping a project into a single archive for package distribution. Hopefully, that will result in smaller packages where dependencies are fewer and intentional instead of the nonsense of stuff like NPM or Maven.
4. ES Modules are a very nice way to manage and organize code. I am using them now with a large Node project I am writing without Node's silly conventions for ES modules. In Node ES modules are experimental and there are virtually no dependencies available that are exclusively using ES modules and feature a TypeScript types library in Node, so if you go down that path you must be dedicated.