Some other Pros: Easier to test individual pieces. Easier to benchmark. More usage == more/better features/functionality for everyone. Easier for people to contribute to without having to know the full stack. I think most people agree that decoupled, reusable modules are a good thing in
general as an abstract concept, but, of course, specifics matter.

I think this needs a bit more explanation. AIUI, the primary cause for concern
is that by making something a module, you are taking a private, internal API of
Solr's and now making it a public API that must be maintained (and backwards
maintained) which could slow down development as one now needs to be concerned
with more factors than you would if it were merely an implementation detail in
Solr.

I feel this can be flipped around and seen as a pro though too.

Taking internal code and making it public can be beneficial for that code,
because it forces the APIs to be examined, test coverage improved, and a general
'kicking of the tyres'. With private internal APIs, there is always a
temptation to make quick changes that meet an immediate need, rather than having
to step back and take more time considering changes. That can slow things down
yes, but it definitely has its benefits.

Other Cons: The concern was that Solr just becomes an uninteresting, empty shell that glues
together modules. (I don't agree, but wanted to present what I have heard)