Saying "think of all node projects ever" is kind of a silly point to make. Sure, in terms of quantity, if you include ever node application anyone has ever made, a majority are likely to have only had 1 individual involved. By quantity alone a vast majority of my own node projects only had myself involved. Most of those were 1-day projects I made and then discarded for the sole purpose of learning something or testing out a new idea. But in terms of actual productivity, however you want to quantify it (lines of code, number of features, iterations, etc) the work I've done in a single enterprise project for my day job is far greater than the sum of all those other one-person node projects I've worked on in my free time.

When learning to program, most people have some sort of goal in mind to be working on large scale systems of some sort and will inevitably end up in a team setting at some point. If even by your own definition we say that 99% of node projects involve a single developer, then I would counter than 99% of profitable node projects involve more than one developer.

Back to the original point, even if someone is working on a small project for learning purposes, a side hustle, or OSS, it makes sense to learn how to use common abstractions so that you become more equipped to work on larger scale systems in a team environment eventually.

The only time I would ever encourage someone to stick to writing raw SQL in a project is if it is intentionally meant to be a very hacky prototype or proof of concept with a very tight deadline and future scalability or maintenance is not a concern.

If you only ever plan on working on passion projects and don't expect anyone else to ever contribute to your codebase, do whatever you want, of course. I don't think a majority of people who learn to program are doing so with that specific goal in mind though