Well, presumably, if you want to give your word processor the ability to "autoSpaceLikeWord95"--for a business use-case, not just as a feature to tick off on a checklist--then you already know what it means to "autoSpaceLikeWord95", because your clients are pointing to documents your program has created and saying that right here, there, and here too, the Word95-like autospacing is missing.
Basically, these compat flags are suggestions to activate the compat functionality it turns out you needed to build anyway; if you're adding compat for some old version of some app because the hook is there, without any of your own clients needing to preserve the old behavior in their documents, you're Doing It Wrong. It would be like Firefox parsing <!--if IE7--> tags just because there's a standard for how IE should handle them.
Firstly, I think it is way more likely they will point to documents they created earlier or that they received over the mail that your word processor does not show correctly (page breaks will change, which means textual references such as 'line 2 of page 3' will break).
Secondly, I doubt they will phrase it as "look, Word95-like autospacing is missing" it's more likely that they will say "MS Word is way better than your #%$! product".
You and I know this is part of some compatibility section of the spec, but if a customer has thousands of documents somewhat depending on those features, you must support it.
In summary: it may not be a matter of wanting to support that feature, but of having to support it.
1. You have an existing workflow built around, say, WordPerfect 6 documents. You've got custom software that understands that format (possibly from reverse engineering).
2. You wish to adopt OOXML as your standard document storage format. You are going to write custom software that converts from your existing format to OOXML.
3. There are things in your existing format that cannot be represented in OOXML, but that need to preserved when you convert a document to OOXML, because your custom software needs that. For instance, your software might need to know about truncateFontHeightsLikeWP6 because it needs to be able to calculate what page something appeared on when the document was printed from Word Perfect 6. (I'm just guessing that font height truncation could affect this).
All they are really doing in the OOXML spec with these settings is acknowledging that people are out there with the legacy preservation needs described above, and giving them a way to all be on the same page (no pun intended!) when it comes to how they can store this information.
Reading the spec, I get the impression that they made a serious attempt to document what these mean. However, some might still find it troublesome that, in practice, the only way to figure out what to do in the presence of such settings is to look at how those applications displayed text or, in many cases, how some Office version emulating WordPerfect or an older version of Word handled them.
Also, some will feel these should not have been part of the spec, or that the spec should be more explicit in stating that new documents should not write them (but then, what is a new document? Say, I do File-New, then paste in a few pages from a document having those settings, then save? Alternatively, I open a document, delete all content, then do File-Save As?)