Trust me when I say this - undo/redo is one of the biggest implementation, testing and maintenance headaches in any significantly sized application.
Granted, it is a wonderful thing to be able to undo/redo something as it relaxes the user and lets them test and explore their environment without worry. However, the usefulness of an undo history starts to diminish right after the first undo. Slowly, mind - but surely.
Full kudos to those that do provide a full undo history, but it is almost certainly as a result of a well planned, well executed approach with a supporting frame work, implemented from day 1, and around which all functionality revolves.
If that framework is not introduced first, it's a major challenge to bolt it on afterwards, and it's easy to get bogged down in it.
The problems lie with:
- The rapidly escalating complexity of testing undo/redo with any possible action in any possible sequence of changes of any size.
- Ensuring that the state of the system after the undo of each step is the same as it was before it was originally done, - e.g. ready for the next undo, or the next redo
- Correct consideration of what is an undoable action
In addition, it is almost universal that if you undo a string of actions and then make another change, you cannot redo all the steps you just undid, because the system has changed state and the redo may well not be valid.
Now one popular use of long undo/redo history is to go back and look at something how it was, and then to go forward again.
I would suggest that the annoyance of not being able to undo more than say 10 steps is not nearly as annoying as undoing 50 steps and then accidentally pressing a keyboard button which throws away the redo history so that you can't redo all that work you just did. I for one get very nervous when I've undone something over a lot of steps, and tend to save first as a fall back, and maybe therein lies the lesson: save often and save versions.
I totally agree that a full undo history is highly desirable - it's just not simple, and that's why it gets dropped down the feature list when tight time and budgetary constraints come into play.