It's not satire. In your case the automated tests are just weak. You call the trunk unstable, because you need extra manual testing. What the page describes is an improvement on that. The CI system should have good enough tests to guarantee your trunk is never considered unstable. Then it doesn't really matter when you make a release - it's not a big deal. (Just choose a commit you like)
I think "pick a commit" only holds up for server based software.
For things like large desktop software with long term supported file formats, mission critical software where people might get killed if something malfunctions etc then it's pretty normal to have manual testing. If the cost of deployment of a release is high (N people training, downloading, installing) then you want few releases - and you can also motivate spending on manual testing to ensure you don't need a new release sooner than necessary.
The release branch also works as a beta/rc branch so that a version is tested on a subset of users before general availability, while things like large refactorings and major features can start being developed for vNext in the trunk/master.
I'm not sure but I'd guess this is how most software other than web and server software is developed.
You're right. But I don't really expect anyone writing safety critical software to get their idea for the process straight off a blog. In that case you'd be going from requirements to how you achieve that. You also don't need continuous delivery. Basically a different world.
