From a conceptual modelling perspective ORM is more powerful and expressive. In my experience ORM is a more effective medium for communicating complex concepts and business rules than either UML or ER - especially if you need to share the models with non-technical users. It doesn't take too long to familiarise inexperienced users with the basics of ORM and it conveys more information more simply than either UML or ER can. ORM also has the potential advantage of the Rmap procedure - if you can use a tool like NORMA that supports it.

A major obstacle to using ORM in the workplace is that software support for ORM and Rmap is extremely limited and somewhat unsophisticated. ER and UML are far more commonly used in practice and there is well-established, feature-rich software support for them.

ORM also isn't much help when it comes to describing a database design or implementation. Rightly or wrongly, the effort and attention given to database design and implementation is often far greater than that spent on conceptual modelling. For that reason software development teams will typically find ER and UML diagrams more useful. Software developers and DBAs will generally be much more familiar with ER and UML notations and unfortunately many of them won't even have heard of ORM (worse still, they probably think that ORM means "Object/Relational Mapping"!)

If career development is your priority then ER and UML are more essential skills to have than ORM. But if you get chance to use it then ORM is well worth knowing as well.