As someone who's worked on both database from the big red O company as well as MSSQL, I can assure you that it doesn't require a new release to cause a query plan regression. A simple change in the data going over some threshold causing the heuristics to be different can suddenly cause a massive performance issue in a production database that has been successfully running for years.
Especially for OLTP workloads, the optimal query plan is often fairly easy to compute and there often isn't "a better one in the future". Having the plan unexpectedly change isn't a feature, it's a bug. Plan pinning and SQL plan management is actually a great feature, unfortunately, it's nearly impossible without the enterprise version, which is literally $$millions$$.
When you're running a web application serving millions of users, consistent performance is key. 10% performance is great, but avoiding hangs, deadlocks, system overload, or 1000x performance regressions is key. Unfortunately, relational databases have tons of ways to encounter the latter. For instance, in Oracle, you absolutely can end up with a deadlock just from inserting rows too quickly--never reading or altering them. Theoretically, this shouldn't be able to cause a deadlock, but on Oracle, it can (Note: it also can on MSSQL but for totally different reasons and depends on isolation level). Hint: It's caused by the ITL (interested transaction list).
Having random deadlocks, hangs, performance issues, spins, or system overloads caused by the database misbehaving only under certain workloads is one of the most frustrating things to deal with in OLTP at scale. If you can't tell, I hate dealing with databases for their unpredictability (and am a huge fan of plan management and other designs to provide better predictability).