Part of the reason it's so hard to get code into NSS is because no one really knows who owns those bits, and so they linger in obscurity. I think my TLS Channel Bindings patch is lingering on 3 or 4 years now.
However, I think you're doing a disservice if you only look at how easy it is to add code. As important is how easy it is to remove code. With NSS, it's far, far harder to remove code - and that makes it far, far harder to reason about any new code you might want to add, for who knows what grues are lurking in those shadowy depths.
Not being able to easily add or remove code is good from a security standpoint though. I would take a bugfix only, stable-API NSS over anything that is in constant flux. So it's not how fast you can add features that should be in focus for a mature product - it's how safely you can add bug-fixes, including security fixes. Unless you are saying you have a security fix lingering for 3-4 years, I think Mozilla is doing it right.
Edit: Not to ignore the valid point - having a designated code owner that responds would of course be good.
It could also be that the public API is too large and exposes unnecessary bits that now make it hard to change even incidental, conceptually irrelevant behavior simply because some user probably relies on it. Even a clean, well documented implementation with active, capable maintainers is hard to refactor when the API is large and intrusive.
(I have no reason to believe this applies to NSS.)
However, I think you're doing a disservice if you only look at how easy it is to add code. As important is how easy it is to remove code. With NSS, it's far, far harder to remove code - and that makes it far, far harder to reason about any new code you might want to add, for who knows what grues are lurking in those shadowy depths.