I'm a humble web developer and I'm not very knowledgeable about databases.
I am glad I deal with an ORM for both personal and work projects instead relying on database specifics. That way, the app is DB agnostic and I can switch the database with ease. If your resource are limited, I think that is good.
When you have the resources, it's better to hire an architect and a DBA to tell you what DB to use and maintain it.
In my experience an organisation is far, far more likely to switch operating systems or hardware platforms or programming languages than they are the database. But no programmer bothers to code in a clever but restricted syntax that would be a valid program in both C# and Java. Or restricts themselves to a core set of OS features or hardware instructions just in case. It really is quite bizarre to watch.
Plus it’s fairly common to end up with more than one program, in more than one language, reading from and writing to a DB. The more you’ve avoided using DB features (in featureful databases, anyway) the slower (in performance and dev time) and riskier (you will have more bugs, and maybe some pretty bad ones) this is.
I don't think anyone would bother to port code from C# to Java in 2020, but I agree with your point. Not using a technology to it's fullest in favor of portability is not smart.
I think most things we build on top are sufficiently complex now that even with these self-imposed limits, porting everything over from X to Y is a major undertaking.
Every developer that works with relational data should learn the basics of ANSI SQL and at least one or two of the major SQL platforms (Postgres, MySQL, SQL Server, etc.).
It’s really not that complicated (if you can figure out redux...) and the knowledge will make you a more well rounded developer. These are skills and knowledge that will be valuable and applicable for many years.
#1 - The administration of a database system
#2 - Being able to write code that uses said system effectively
If you don't have skillset #2, you are going to design and build bad systems and eventually a DBA will need to bail you out. The trend is that companies are reducing the number of DBAs on the payroll because of things like AWS Aurora, so you had better get skillset #2.
And why wouldn't you want it? It's like knife skills for a chef. You should know your tools inside out.
I am glad I deal with an ORM for both personal and work projects instead relying on database specifics. That way, the app is DB agnostic and I can switch the database with ease. If your resource are limited, I think that is good.
When you have the resources, it's better to hire an architect and a DBA to tell you what DB to use and maintain it.