At my current place of work, we have this strategy and I think it's a mistake. app/lib is just another way of writing app/service. It becomes, over time, a chaotic place where everything goes. If it doesn't fit for _any_ reason, app/lib becomes the place where those files live.

The benefit of lib/ is clearer in my opinion. Files that live there are only explicitly loaded. Some might be loaded in development, some in production, some in test. The conversation about the structure becomes more important because you need to think about what is going to consume your class.

But I think we could take this a step further and instead replace lib/ with engines/. This way, you can create multiple Rails engines that will have their own paradigm and environments' handling.

Every Rails application I got to work on had a lib/ (or app/service) that could have been grouped in a few different engines/. The benefit of using those kind of engines is that conversation about architecture, pros/cons get more defined. At least that's been my experience.