Although certainly intentionally not sharing knowledge can be unintentionally rewarded I don't think the author's issue is with poor knowledge sharing so much as unintuitive code that requires knowledge sharing.
CVE-2023-2640 and CVE-2023-32629 if you don't fancy spending an age clicking Object to all the 'legitimate interest' cookie shit.
It's almost as if devs have found a new way to have their code written for them... 😅
No, but I do work as a developer and we work pretty closely with the testers. Not back in the day though, I'm not that old but I've been around enough to know that even in the current era of software development the quality and duration of testing varies quite a bit from company to company. Some companies really don't care and the testing is token at best, others like where I currently work are quite obsessed with quality and dedicate quite a lot of time and people to testing a release before it goes out. Of course there are still bugs from time to time but a lot are found and fixed during testing.
Previous companies I've worked at with not-so-great testing were more consumer facing whereas the current one is B2B with a lot of enterprise customers so maybe companies just put as much or as little effort into testing as they think their target audience is willing to put up with.
He's not exactly comparing software to netscape or win 3.11 though, he's comparing version N of some software to version N-1 or N-2 and noticing that they're getting worse from release to release. Given the rate of new releases the complexity shouldn't be increasing that rapidly between releases so I'm not convinced that is the cause per se. I have to agree with the conclusion from the article, testing was more rigorous in the past than it is now. Both because there was less surface area to test back then and because time-to-market pressures were less due to the longer windows between releases.
I feel your pain because as you say these Lutzes are everywhere but I think you hit the nail on the head when you say, "simply paying the person until they choose to leave and tank some other team's / company's productivity is less risky than firing them and potentially having to deal with a lawsuit." This absolutely is the reason why it's so hard to get rid of these people.
We've managed to get rid of two such Lutzes on our team in the years I've been in my current job and on the first occasion it took over six months for the managers to build a sufficient case to just put the Lutz on a Performance Improvement Plan. The hope was that said Lutz would take the hint and jump rather than be pushed and luckily for us that's exactly what happened and the second occasion was just luck as not long after we started complaining about them the mass layoffs in tech started happening and we got rid of them as part of that (though we sadly also lost some good devs in the process).