In software engineering there's rarely an objective way to answer "better" or "worse", it's more often a question of trade-offs.
An ORM is the choice to trade some performance and a little complexity in exchange for some convenience.
This is of course a simplification, there are other aspects to be considered.
Personally, it seems to me that this is a trade-off which is often valuable.
That being said, it's not necessarily the case that by using an ORM you are not using SQL. There are ORMs that offer you a way to abstract away SQL, others take a mixed approach where you use SQL to define structure and migrations, but use the ORM to manipulate data, for example.
What's more, each ORM has a slightly different set of features, depending on what their authors thought would be better. There's no universal "correct" way to build an ORM.
In some situations the loss of control you get when using an ORM is not worth it, because one could write better queries by hand. In other situations it might lend itself. Also different people will have different experiences and a different skillset, which also leads to different decisions.
It's all about what makes your life easier in terms of building maintainable software in the specific situation you find yourself in.
