If you configure your notification emails to include the posted text, then you could have a record of the original on your own email archive. But aside from indicating that the post has changed it wouldn't be hugely useful.
When IPB prepares the notification email it could store the text in a server folder "edits" similar to "uploads" - i.e. the text would not be in the database. The database would just have references to the material in "edits". This would be only a small increase in database size. (No free lunch - the disk usage on the server would increase).
We've had IPB since 2004. At that time BBCode (Bulletin Board Code) was the natural thing to use.since our users and staff were mostly accustomed to using bulletin boards. Very few people had any problem with the tags and there was good built-in help with it when needed, We still need it when using our Canned Speeches. To go over entirely to HTML would be a massive rewrite for us . Surely "massive rewrite" is more appropriate for the vendor to do than for us to have to do.
As it is, staff has to do a good deal of editing via BBCode to get our posts to look right. What is maddening is that even after editing, if we copy the contents of the post and replace our stored text with that, it tends (seems random) to have the extra line problem when used again.. .
I find the 3.4.2 editor quite usable and as noted, a big improvement over 3.4.1. But I wish IPS had just stuck with BBCode and never attempted HTML. It seems to me that storing and retrieving BBCode text is more compact and simpler and bug free. Why store HTML. anyway? Apparently IPS was aiming for the WordPress market rather than limiting the product to forums. No doubt some IPS customers like being able to easily design fancy web pages but although the WYSIWYG is very nice sometimes it isn't anything we ever felt the need of.