I sometimes wish I could directly write a plan for my query instead of relying on the db to come up with something that matches it (OLAP). The other 90% percent I’m happy that it just works.
There's a huge difference between one-time queries (let the planner figure it out) versus production queries.
I've been bitten in the past by the SQL planner failing as it reaches some threshold and suddenly stops using an index it was using before, etc., and queries go from taking milliseconds to seconds. It's rare, but it happens, and the results can be catastrophic -- usually because it starts ignoring an index because it (wrongly) thinks the index would slow it down -- planners aren't perfect.
I'd much rather specify in advance the query plan to handle what I knew would be the eventual biggest-case scale of data: to always use X index (forced, not just hinted), and to deal, in advance, with whether or not sorting will always be possible in memory or if it will need to be done in a swap file on disk, and at what points filtering happens.
I actually don't care if this slows down my (already blazing fast) queries 10x or even 100x when the database is small (e.g. by sorting on disk instead of in memory, even when just 10 rows -- or using the index even when clearly unnecessary with just 10 rows). It buys me the peace of mind that there will be no discontinuities in performance in production, no surprises.
Of course this isn't for basic grab-a-row queries: I'm talking about more complex queries with all the bells and whistles (subqueries, multiple joins, filters, etc.) where the database's planner goes haywire.
[1] https://docs.oracle.com/cd/B19306_01/server.102/b14211/hints...
[2] https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html
And the very static case is the easy one in OLAP. You build a star schema that is so simple that the planner could not get it wrong. To fill this schema you use some ETL tool that very much resembles a static plan.
In the dynamic, exploratory phase (does it make sense to look at the data this way) you have to deal with the nasty complicated queries.
If you want to have that exact behavior I'd agree with the gp, we are talking about data access, but not all data access has to be a SQL database.
Index hints are just that, hints, they are not commands - because there are tipping points that they just dont make sense anymore.