Totally. ORMs are not evil. They help to reduce the boilerplate and improve the code maintainability.

We have a complex project with a custom back-end framework that also includes a custom ORM. The ORM covers about 95% of the use cases just fine. It reduces a lot of boilerplate and also makes it possible to find the logic much easier (for example, setting and reading some column from a specific table). Although I have to say, it works that well also thanks to good integration with the framework (fronted, included) and advanced features, like calculated fields with automatic recalculation triggering, integration with user permissions, ability to define custom user permission validation logic before / after saving rows, etc. If we really need an unusual operation where the ORM doesn't suffice (most of the time complicated search queries or some aggregation), we can write raw SQL and, if possible, encapsulate it at repository / service level. But 95% of use cases are covered by the ORM (including the management of parent / child relationships).

I think some "old school" folks like to bash ORMs and view them as very limited and inefficient compared to raw SQL. But you can use them both: primarily ORM and in specific cases switching to raw SQL when ORM doesn't suffice.