I'm not quite sure I understand. Speaking of the generic case, the (quite broad, I admit) statement that modular and composable functionality should enable both the unified-libraries-approach (or frameworks) and pick-and-choose-approach should (when applied) solve the OPs problem of not wanting to use what he/she doesn't need, shouldn't it?

I support the idea of a framework essentially being a light-weight layer on top of libraries, but if the framework just uses a single monolithic library then little (but something!) is gained. If it uses one or more libraries that are all properly composed of smaller modules, etc, etc, then a lot of flexibility is gained.

I'm not very familiar with Rails - especially its internals - so it's hard to comment on this particular case. However, making job queueing modular seems to have found the approval of most people in the commit comment thread you linked.

But I agree that the distinction is never clear cut, and everything needs a discussion on a case-by-case basis...