This is a good example of why knowing the database matters!
I see too many work with data intensive systems where these kind of problems pop up that seem oblivious about what is involved to get performance and how the server ticks. Most as a result of simply not knowing enough about it and only seeing the SQL itself as a means of getting data out of some dumb storage.
Your case nicely illustrated what is involved and what understanding and reasoning is required to tackle these and similar, but smaller issues. I had to deal with such things in the past, and learned to try force order on cases where the optimizer isn't up to the task time wise. Query plans don’t always get full optimized and in complex cases there are simply too many options to evaluate and you can get stuck with an awful plan.
A complementary habit I have is to write queries in such an order that 'optimize (force order)' directly gets the best possible route to the result. Doing this means the query is easy to understand too as each join can be read as a separate step in a process and understood on its own (indention helps too here). This means all filters that can be applied to a join are found on that join and not hidden half a page away in the where clause. Just reading the join and knowing the consequences is so much more direct then having to decipher a whole query before you can begin to understand what the intention is :).
Good job and nice article!