OK, so I've been toying with different ways of organizing my Rails 3 apps regarding STI and Polymorphic Associations. I was trying to find a way that is both easy to code, and easy to use, and has the highest chance of being the most compatible with any future changes. After alot of reading a lot of optionated (and often lacking and poorly written) articles, I've come to some conclusions of my own.
First, it seems that using STI is the safest bet, in terms of being easy to code, easy to read and use, and easy to work with any future changes without too much re-writing. The only legitimate downside I can see is that in your DB there will be "holes" in the data. Some ppl think that this is a bad thing. But, IMHO, if this is the only downside and the upshot is making the rest of your life a hell of a lot easier, then WHO CARES?
Second, it seems that Polymorphic Associations really only work nicely in certain situations, definitely not ALL situations. Moreover, it seems that any situation where you COULD use Polymorphic Associations, you could also just use STI (and not the other way around ). So why bother with Polymorphic Associations at all? Just to get those pesky "holes" out of your DB? But then you are adding duplicated fields and extra tables that look an awful lot alike, not to mention multiple sets of controllers and models and views etc.
Third, even if you do identify a proper time to use Polymorphic Associations, and properly implement it, things could change and you would find yourself having to rip out the Polymorphic stuff and end up implementing STI anyways. I'm not seeing a time when this would happen the other way around. STI seems to play nice with any setup, whereas Polymorphic Associations seem to need things to be "just so" in order to work as advertised.
Now, I'm not the smartest guy, so these could be wrong-headed and/or short-sighted observations - Please let me know if you think I am wrong, and try to provide some good evidence to support your case!