Changing databases on an existing application doesn't happen, but I've worked across teams within a single company for ~8 years and in that time I've used:

1. SQL Server

2. MySQL

3. Neo4j (very briefly)

4. PostgreSQL

5. DynamoDB

Each of those was for a different set of applications, and none of those applications changed database, but point being sometimes an engineer will be made to use a variety of databases in their career, even sometimes within the same company (although you could also chalk this up to a particularly laissez-faire style of tech direction).

Exactly.

In our case company was strictly "Oracle-only", but one team did a quick implementation in startup-style of Rails and used mysql. No one forced them to migrate to oracle, company just hired DBAs that now mysql.

Changing the database for an existing system happens very rarely, but changing the ORM or language is even rarer. So learning the ORM well is just as rewarding as learning the database well, IME - and more so once you take into account changing jobs, since you're more likely to take another job using the same ORM but a different database than vice versa.

It is good to know both. I wouldn't choose which one is more important (ORM vs pure DB) as both are useful.

But you can use DB without ORM, you can't use ORM without a DB.

Hibernate (and generally JPA) is usually more PITA than help, it makes easy things easier and hard things harder.