That has nothing to do with the release cycle. Chrome and Firefox have very complex codebases and four-week cycles, and every release is rock-solid. Bugs exist, but you don't get a stability rollercoaster every four weeks. macOS has a one-year cycle and every release adds a ton of bugs, most of which only get fixed in the next major release (which adds its own bugs). This is a QA and management issue.
I also think if the products he produces need 15 year support he should choose operating systems that provide that, for example QNX comes close. Instead he chooses to complain about a OS that have never ever promised anything like this and that he can get for free.
We don't live in a world with infinite supply of interchangeable operating systems that only differ in one interesting characteristic. For most software products out there there either isn't a choice at all, or the choice is between bad and worse.
But this isn't even the point. Someone, well, a group of people, made a decision about how long the support for the system should be. OP believes they were wrong. Telling them to try a different system solves nothing, even if that worked for them. The conflict is still there: someone made a bad decision, even if OP no longer actually needs to rely on their decision, it's still bad.
The article doesn't say that. It says that proclaimed LTS releases aren't such. The article says that all we have is short-term-releases, it doesn't go into details on how much we should pay for the lengths of support of release at all.
I don't see why is this a problem to want to make more money, the easier the better, imo. The author never claimed that they aren't willing to pay for any services though, so you are putting words in their mouth. But, let's for the moment say they wanted to pay for real LTS releases instead of what we have today -- they need to convince many people to share the brunt of doing so, otherwise it's going to be very expensive for them. Their disappointment comes from the perception that a lot of those who would potentially benefit from sharing this expense with them don't do that by following short-term gains and disregarding long-term losses.
---
From my personal experience: we dig ourselves a hole with creating short release cycles. We ended up in a situation where every new iteration of software we release is of despicable quality and there's no hope of improving the quality because the next release is already on the horizon and most and best resources are dedicated to it. Releasing often is seen as a primary driver of profits. This acts to demotivate and devalue QA teams, who, in the present day are seen more and more as a waste of resource and are even sometimes repurposed to do things unrelated to QA, s.a. release management or even customer support. And, I think, this is what the author talks about when they talk about how agile is a bad thing.
The ultimate claim the author makes is that we don't really need short release cycles. Not the individual users neither the companies no matter how big. We'd benefit from higher quality software released less often. We don't need to pay extra for longer term support as you put it. What you perceive as longer term should be the norm. We chose the wrong driver for companies profits -- selling new versions works, but leaves customers more and more dissatisfied with the results. Perhaps, we should think about a different way to pay for programmers' work? Perhaps instead of version upgrades we need to sell maintenance? -- I don't know, and am not enough in the know of how the profit is made in this instance and where it's possible to take it.