IMO it was always a fundamental mistake to force the programmer to deal with the event loop by default. Run async in the background, but present as sync to the developer unless otherwise requested, would have been a much saner design. Unless you're developing a framework or library, odds are good your ratio of leveraging async versus contorting yourself to make it (from your script's perspective) go away will be 1:10 at best.
JS keeps coming up with new ways to make this less painful, but it's ridiculous every time because it's a fundamental problem with how Node presents itself. A comical sea of "await"s in front of damn near every call is the modern version of this, and is utterly typical in real JS codebases, but before it's been callback hell, or screwing around with promises all over your codebase when 90+% of the time you just wanted things to execute in order (from your perspective), and so on.
I think it's also made much worse by how JS doesn't care about whole classes of bugs. Forgot an `await` somewhere or called an async function assuming it's sync? Now you've got a bug and in some cases no idea where to look for it. TypeScript is also blind to it (although now that I think of it a linter might flag it?).
A really good point, and all the more reason to make developer-visible async behavior something the developer has to to ask for, even if the call is in fact async under the hood and might let, say, code handling another request run while it's waiting on I/O.
I think a pattern where there are one or two great places at the lowest level of a Node program for program flow to act async, and then a bunch of business logic where it rarely is (probably running "under" the part where async makes sense, if you take my meaning) is far more common than those where async-friendly flow is what you want for over 50% of calls. "Call this chunk of code async, but run everything in it exactly in order" is super-common, and the interface to achieve that is exactly backwards in Node.
I can't even count the number of times I've seen a unit test giving a false positive (or, perhaps more accurately, not even run) because the developer forgot to properly use async/await or use the done callback.
Linter flags when you put an await in front of a-non async function, but, alas, the opposite is not true (call of async without await). This has always been source of bugs in my code.
JS keeps coming up with new ways to make this less painful, but it's ridiculous every time because it's a fundamental problem with how Node presents itself. A comical sea of "await"s in front of damn near every call is the modern version of this, and is utterly typical in real JS codebases, but before it's been callback hell, or screwing around with promises all over your codebase when 90+% of the time you just wanted things to execute in order (from your perspective), and so on.