I'm not sure, but I guess finding out if there is an index to use is less expensive an operation than to find out what index should be created to speed the query up by what extent.
I fear that adding a feature to find out what indexes should be created would significantly slow down every query to the database. But then again, if the feature is optimal, you can for example turn the thing on during developement (or even during end-user testing to get significant data), let it do its work and then turn it off.
The other problem is that the more indexes you have, the more expensive the operations become. That means that you can't just analyze one query. You'd also have to take into account the amount of inserts happening on the tables you are auto-indexing.
And there are different types of indexes. Which one is best? Should the system create a unique one? And if the system provides multiple different technical types of indexes: Which type to use? All that makes implementing such a feature quite difficult I guess.
But I agree: I really think software should be smart enough by now to find a useful solution here. Too many times I've been bitten by suboptimal (or outright missing) indexes. And there's more fun stuff to do than manually analyzing query plans the database is throwing at you.
At least for me, that is.