For a document author used to HTML, XHTML is clearly a more painful and certainly a less forgiving document markup language. Whereas at one time we prided ourselves on being able to crank out HTML with pencil and paper, it's much more tedious to write XHTML without special document-preparation applications. Why should any author want to take on that extra baggage?
Over just a few years, authors have generated billions upon billions of web pages. It is a safe bet that the majority of these pages are not compliant with any defined version of HTML. It is an even safer bet that the vast majority of these pages are not XHTML compliant.
The harsh reality is that these billions of pages will never be converted to XHTML. Who has the time to go back, root out these old pages, and tweak them to make them XHTML compliant—especially when the end result, as perceived by the user, will not change? Like the dusty decks of COBOL programs that lay unchanged for decades before Y2K forced programmers to bring them up to snuff, these dusty decks of web pages will also lie untouched until a similarly dramatic event forces us to update them.
However, the dusty-deck problem is no excuse for not writing compliant documents going forward. Leave those old documents alone, but don't create a new conversion problem every time you create a new document. A little effort now will help your documents work across a wider range of browsers in the future.