I've explained in another thread how this kind of thing happens. It may be the same at other large companies.
Bugs come in (via Radar) and are routed to the team responsible. Ever since Jobs came back (and Apple became valuable again) it has also become very much top-down with the engineers, for better or worse, not calling the shots.
Just an obvious example — there are of course no engineers in the decision to make a "Snow Leopard" release or not. That is a "marketing" decision (well, probably Federighi). But further, even for an engineering team, they're probably not going to be able to make that decision even for their own component(s) either. Again, marketing.
So meetings are held and as it gets close to time to think about the NMOS (next major OS) the team is told what features they will implement. Do you think fix bugs is a feature? How about pay down technical debt? Nope, never.
Fixing bugs is just expected, like breathing I guess. And technical debt ... do what you can given your workload and deliverables. Trust me, many engineers (perhaps especially the older ones) want to both fix bugs and refactor code to get rid of technical debt. But there is simply not the cycles to do so.
And then what is even more insipid, the day the OS ships, every single bug in Radar still assigned to a team, still in Analyze, becomes a much much harder sell for the next OS. Because, you know, you already shipped with it ... must not be that bad.
I'd love to see a bug-fix-only Mac OS release. But I suspect that every time the possibility has come up, something like, I don't know, LLMs burst on the scene and there's a scramble.