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.