I think partly the reason is that the document model of notebooks is quite complicated. Each notebook is a hierarchy of Mathematica expressions (technically, the box versions of the original Mathematica expressions) and an associated set of cascading style sheets that tell the frontend how to format things. There are some nice advantages that stem from this meta-homoiconicity, but also some disadvantages.
One of these disadvantages is that editing the notebook does quite weird things to this hierarchy, like embedding new cells inside existing ones, merging cells, and changing mutable state in the frontend in various ways. Figuring out how to intelligently support multiple levels of undo without leading to rapid garbage generation and/or corruption is I imagine a Hard Problem.
For the record, another disadvantage is that source versioning and diffing is nigh on impossible (unless it takes place at a higher level, which is an interesting idea I think the company should pursue).
One of these disadvantages is that editing the notebook does quite weird things to this hierarchy, like embedding new cells inside existing ones, merging cells, and changing mutable state in the frontend in various ways. Figuring out how to intelligently support multiple levels of undo without leading to rapid garbage generation and/or corruption is I imagine a Hard Problem.
For the record, another disadvantage is that source versioning and diffing is nigh on impossible (unless it takes place at a higher level, which is an interesting idea I think the company should pursue).