That's not "everything we know" as in some gospel accepted by everybody.
"Release early, release often" is just one mantra of a particular development philosophy.
But honestly, it's not that big of a deal. I've got code from v0.12.0 that still works on Node 8. People are making a really big deal out of nothing.
The longer language developers hold back changes, the less time it gives language users to upgrade. What would you rather them do? Sit on defect and security hole fixes? Just because you're uncomfortable with the rapid pace of technology change? It's the Singularity dude. It's not going to slow down. You either learn to live with it or end up in the same pile as FORTRAN programmers.
I'm speaking from a users' point of view. If one program works on Node 8, other on 6, other on 0.12 sth., what do I do? Keep n runtimes for n programs? I don't know node, but I don't know C++ too, should I not use Firefox or Chrome then? Node runtime versions are unfathomable for those who don't develop on node, and thus as a user I avoid running node programs.
Also, security fixes and bugfixes are expressed in semver w/ the last dot-seperated part of the number, the first number is the major version. If every fix breaks as much to bump up that number, then that's a bad sign too.
No, there isn't. This flies in the face of everything we know about software quality. "Release early, release often". Rapid iteration. Continuous integration.
Smaller releases are easier to upgrade through. It creates a clear path through which to modify legacy code to come up to date with the latest version. Big bang releases create too many issues all at once that people tend to stick to the old version and then bitch about it for so long that even if you do make turn-key upgrading an option, they still won't do it coughPythoncough.