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?
I think it's intended to just be a "better node" in as many respects as possible. Better security, more coherent module/package system, async/promises from the start rather than hacked in, first class security/sandboxing options.
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
Also scripting feels nice in Deno so far. Also the ease of using a script written by someone else hosted on the web to do stuff, without worrying it taking over my machine, is cool IMHO.
1. A secure environment. You must authorize access to libraries like the file system or network interface. By preventing access by default you can write systems automation that is arbitrary computation resident in memory not intentionally leaking outside the computer.
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.
[0]: https://news.ycombinator.com/item?id=22103054