My search on the topic brought me here, so I'd just like to share my recent experience on the topic.
I was running SQL 2014, so I figured that I would be safe from having to care about 4199 for a little bit... but it just wasn't true...
How to Diagnose if you need 4199
If your query appears to run poorly, particularly when you feel it shouldn't, then try adding the following to the end of it too see if it fixes all your problems, as you might need 4199 ("Enable all Query Optimizer fixes.")
In my situation, I had a top 10 clause blowing up a query that ran fine without, which is what made me think something fishy was happening, and that 4199 might help.
Any SQL Server Query Optimizer bug/performance fixes that are created after the new major version release actually get hidden and blocked. This is in case they might actually harm some other theoretically perfectly optimized program. So, install updates as you might, the actual query optimizer changes are not enabled by default. Therefore, once a single fix or enhancement has been done, 4199 becomes a necessity if you want to take advantage of it. As many fixes show up, you'll eventually find yourself turning this on when one of them affects you. These fixes usually are tied to their own trace flags, but 4199 is used as the master "Turn every fix on."
If you know which fixes you need, you could enable them piece-meal instead of using 4199. If you want to enable all fixes, use 4199.
Ok, So you want 4199 Globally...
Just Create a SQL Agent Job which runs every morning with the following line to enable the trace flag globally. This ensures if anyone turned them off or etc, that they get turned back on. This job step has pretty simple sql:
DBCC TRACEON (4199, -1);
Where -1 specifies the Global part in DBCC TRACEON. For more info see:
"Recompiling" Query Plans
In my most recent attempt I had to enable 4199 globally, and then also remove existing cached query plans:
Where the recompile stored procedure finds any query plans relating to the database object (such as a table) and deletes those query plans, requiring the next attempt to run a similar query to compile them.
So, in my case 4199 kept the bad query plans from being created, but I also had to remove those that were still cached via sp_recompile. Pick any table from the known query affected and you should be good to try that query again, assuming you have now enabled 4199 globally and cleared the offending cached query plan.
In Conclusion on 4199
As you utilize indexes, a smart query plan optimization becomes important to actually using those indexes intelligently, and assuming that over time some fix to the query optimization process will be released, you're generally in safe water to just run with 4199 globally enabled, as long as you realize that some new fix might not actually play as nicely with a highly optimized database that was such optimized in the prior environment before said fix. But what does 4199 do? It just enables all fixes.