I'm a Quality Engineer, and have worked for a number of large and small companies in the Valley after moving into quality from software engineering 13 years ago. I've seen a lot of teams.

Problem is it's a feedback loop. A lot of companies maintain (or did maintain) armies of unskilled people who basically were script executors, with maybe a bit of barely-trained skill in finding equivalence classes and boundary testing so that basic test plans could be written.

I wouldn't even call this QA, even if it was misidentified as such--it's Quality Control to catch problems after the fact, with no front end assurance whatsoever. It's honestly really only good for pissing off people when you stop the shipment at the last minute. And that lack of value has been broadly recognized. When you combine the high cost associated with the brute-force documentation associated with verbose test scripts, result templates, and other prehistoric process artifacts aimed at this level of tester (and which are usually simply unnecessary and actually detrimental to agility and pace) it's no wonder they're being cut.

Problem is as classic brute force QA teams get gutted, the market has been flooded with these testers, and most of them kind of suck. Hiring a decent quality professional has gotten damned difficult. And when everyone you meet with "QA" in their resume is a non-technical, uninfluential yo-yo, you get a pretty bad impression of the discipline.

In the meantime, everyone as skilled, interested, or immersed as you describe has been moved into software engineering, because QA was treated as an "entry-level" position and nobody wants to be a non-technical, uninfluential yo-yo. The rise of the Software Engineer in Test is as much a collective gambit to keep skilled people in quality as it is identifying a new skill-set. And for people in my line of work, identifying yourself as a SET has about a 30% pay differential over identifying yourself as a QA Engineer, so there's plenty of incentive to move in that direction.

But even then, the rise of the SET reflects an over-reliance on automation, and an under-reliance on process-based quality improvement and the type of fuzzy testing and intelligent guessing only a human is going to reasonably provide. The net result is that edge and corner cases escape, because automation is pretty shitty at catching those unless a fuzzer or an automated monkey (which is essentially a UI fuzzer) can be used. Generally, you only find problems where you've programmed it to look, which will be necessarily be pretty narrow, and the automation cannot use discretion to vary off the script to where new problems actually might lie. People have conflated the value of QA with the value of bad QA, and have chucked it out the window without understanding the cost. I'd guess that many have never even seen good QA to understand what it can do.

Nevertheless, this particular story is egregious. However much you cut back on quality control or assurance, the ONE FUCKING THING you always guarantee is that the user can get out of any problems that arise with minimum damage to money, data, time, and customer goodwill, roughly in that order of priority. Bugs in updates that kill your code signing stack and block further updates are just plain unforgivable.