It's generally due to the separation of presentation and logic. Particularly in the MVVM world. It's certainly doable though.
Let's take a simple MVVM example (Assume C# and WPF here, but this should be general purpose)
In my application I have a Paste button, which is bound to a
PasteCommand in my view model.
PasteCommand has a
CanExecute handler that returns false if there is either no data on the clipboard, or the data on the clipboard is in a format it can't use.
Now all your
CanExecute handler can return is a
boolean. It's got no way of saying why in that method.
Since your command doesn't know anything about the view, it can't just go ahead and set the tooltip text of the button to something helpful. That tooltip text has to be bound to a property in the view model.
Suddenly this all stops working, because it means that you need a property in your view model for every control that you want to display a reason why it's disabled. Messy and unmaintainable.
Now there are ways around this, if you had a class that inherited from
ICommand which had a
FailureReason property and used that for your
PasteCommand - you could then bind the tooltip text of the disabled control to that value (but only do so when it's disabled, which you can do with WPF) - although technically this breaks some design rules as the view then becomes dependent on your implementation of the viewmodel and the custom command class.