Except in this case there's no signs that anyone was being particularly reckless, lazy or disregarding the rules, it was a fairly complex interaction between debug settings, ASM optimizations and dependency management. This is more like when the Space Shuttle blew up and nobody cares about the 9999 parts that didn't fail because the O-ring did and as a result it's now small chunks of scrap metal with dead astronauts. You don't get points for effort, style or the parts that work it's the end result that counts and in this case GCC poops on the floor because the final output is shit.
I think it's a good attitude for a kernel manager, because when he gets shit code from driver or subsystem maintainers that goes into a release kernel and starts corrupting data and throwing panics the shit is going to land on him. You can't just shuffle that responsibility downwards and say no, the kernel is 99% fine but that driver is crap because as far as the end users are concerned the kernel is crap and the internal bickering about whose fault that is doesn't matter one bit to them. It's your project and your job to get it fixed. And that might require some harsh words about the O-ring and the people who made it, because it's making them all look bad which is totally unfair to everybody else.