Moving some comments here from a Phab discussion (T221177):
IMO there should be more discussion about librarization. There are two levels of it: extracting utility components which have wide applicability outside Wikimedia (and typically don't change much) which is mostly about good OS citizenship / developer engagement, and does not affect code quality much, and tearing the entire codebase into independent modules (a harsh way of enforcing decoupling, basically). There was a 2014 librarization RfC but it's not very clear which version of librarization it was about (it talks about un-monolithizing MediaWiki, but also about not breaking up core) and there was not much discussion of the cost ("componentization" makes life easier for contributors, but harder for maintainers who need to deal with the overhead of versioning, updating depending modules and so on). Also, some of its assumptions didn't really withstand the test of time - it talks about a service-oriented architecture, but it's not very clear whether we are still committed to that today; it talks about the ability to swap out components, but since then we have a dependency injection framework which already makes that possible (and wasn't really written with componentization in mind). So IMO there should be a discussion about the librarization of not-really-reusable components before we put much effort into it.
Also, the librarization project is IMO not very mature - a lot of the low-hanging fruit got done, but the fundamental questions were not touched. How does dependency injection work for a librarized component? How does it integrate with the hook system? The i18n system? Would it use /vendor (so version bump + double review for every patch that needs to be deployed within a reasonable timeframe)? Those questions could use more thought and discussion.
I do think that the full decoupling version of librarization is probably a good idea, I just feel that we haven't fully thought it through, and also that a lot of people do not realize that it's planned or what it really means, so it needs more buy-in.