Aside from being transactional, which is the opposite of limited.
I might see lamenting the lack of CASCADE but I've come to be less than fond of that in postgres, I don't consider that a feature.
And since mysql does not have DROP COLUMN ... CASCADE does it just... destroy any dependent when you try to drop a column being depended on? That sounds like the opposite of a feature.
Otherwise, assuming there's no FK and it proceeds:
If the dropped column is used in any indexes, the index definitions are adjusted to no longer be keyed on that column. And if there's a single-column index on that dropped column, the index is also dropped. It's pretty much what you would always want to happen, without forcing you to needlessly indicate how the indexes need to be adjusted.
It doesn't automatically adjust any views, triggers, procs, funcs, etc that reference the column though.