Being honest, I find ROM quite complicated and verbose. Still there was a huge cognitive issues trying to understand what is different in ROM 3.x (where hanami-model stuck) and ROM 4.x we had a lot of confusion in documentation of ROM, while trying to find out “how to make this ROM feature working in Hanami”.
Also it still not very clear how to use pure ROM, while having migrations and what is even more important - correct code load sequence (in dev env with Shotgun reloads). Also we had troubles while composing complicated JOINs in ROM or making “soft delete” functionality (and making it not verbose).
In general at the moment of making a decision to switch to Sequel our team was already a little biased against ROM. Even more - we use Sequel-Model. In general ActiveRecord as a wrapper to make SQL queries is very fluent and clear.
So we have a mixed architecture now - there are still hanami-model in the app, it serves “native” hanami migrations and there are still 5-7 entities / repositories that are using “legacy” ROM inside, but they are too large (but independent in terms of relations) to rewrite them now (or there duplicated of the same Entity and Sequel Model - to serve automatic relations).
All other functionality is made with Sequel Model wrapped by custom repositories to hide queries details. And it output array of Sequel Models (minus here is that these models could be modified and saved outside of the Repo, but we handle it via code review and convention “all find/save/update inside a Repo only”). And there is still a minor issue due to code [re]load sequences, because there is no clear docs how to inject own step to load Models in the chain of hanami-container initializations.
Yes, it’s a bit awkward… but it works fine, with a bit of team discipline