Because they are another form of coupling which is hellish to get out of if you want stuff to be portable, which as we found out when SQL pricing went through the roof is definitely a desirable feature in your application...
Also we use an ORM (NHibernate) which abstracts the entire query and schema away from us. We load/perf test that and get on with life. If there are any blockers, it's 99.9% architectural or loading related which we cover with test cases.
For us, the database is the hole we put our shit in when we don't want it in memory any more. Nothing more.
In your other comment, you mention that "our hefty DB cluster has lots of cores", and that this caused licensing to be much more expensive. Have you considered that maybe the abstractions and attitudes you're using have inflated the amount of hardware you need?
NHibernate, for example, can make it extremely easy to generate extremely poorly-performing queries. It often takes much more care and effort to have it generate mediocre queries than it takes to write good queries and any binding code by hand.
The "abstracts the entire query and schema away from us" and "database is the hole we put our shit in when we don't want it in memory any more" attitudes don't help reinforce the idea that you guys know how to use relational databases properly.
When teams go out of their way to remain as ignorant as possible about relational databases, while also using abstractions that are often inefficient, they shouldn't be surprised if their hardware needs (and their licensing costs, in some cases) balloon due to this inefficiency.
The question is, what's cheaper- labor for optimizing the queries + paying (possibly reduced) SQL server licensing, or keeping the "mediocre" queries + throwing in more hardware?
99% of the hinting I've seen people "need" was not needed at all, it was just the lazy way to temporarily work around a bad query plan. Other than actual bugs in the query planner, I can't even invent a hypothetical scenario where the tools postgresql already gives you to influence the query planner couldn't solve a problem.
