The reason you can't do this is that Node of course has a bunch of file system APIs that for security reasons necessitate an application designed for automatically downloading and executing arbitrary source code can never, ever, have access to.
But you could rephrase the authors point this way: Browsers make a ton of concessions to regular users at the expense of developers. Consider for example that the act of developing a web application in fact often does not involve executing arbitrary source code online, it involves executing specific source code you have control over, which has different security requirements.
The author is expressing something I'm surprised more developers don't pick up on: The browser is a consumer tool first, and yet it's a favorite tool of developers despite the fact that it barely caters to developers at all. Take for example the "Developer" menu item, which is two levels deep in Chrome. A rational developer, who spends all day with a browser open for development, would be frustrated that one of their primary use cases has such a low priority in the application. But that's not how developers perceive the browser, developers have a fondness for the browser that's not reciprocated.
Another example of the low priority of developer use cases in browsers is that the commonality of the other main developer tools, text editors and terminals, is that they achieve incredibly powerful functionality through process management. E.g., code completion, linters, integrated debugging, `grep`, `git`, are all based on text editor's and terminal's ability to manage external processes. But browsers can't do this, which firmly limits their usefulness, and creates bizarre situations like having to manually hit the refresh button because your server process can't talk to the browser application itself.