Skip about 1/3 of the way down and the OSM article starts. “This is why bad design is everywhere...”
Ironically, 95% of this article is irrelevant fluff that does not make it any easier for the reader to understand.
That's actually a sensible design. Treat user-facing stored data as user interface. If you need efficient processing of that data, such as fast parsing, you can always build it elsewhere, such as by caching that data into an intermediate structure that is recompiled whenever the user data changes.
And, you're suggesting that user-facing data should be harder to work with only to make it faster to parse?
But seriously what's up with this total disdain for anyone trying to build applications with OSM data? You don't seem to care whether parsing is near instant or as other commenters have mentioned, literally a majority of total processing time for certain compute jobs
Are you telling me, the main mode of contributing to OSM should be to edit XML files and put in GPS coordinates by hand?
That would be about the most user-hostile UI for map editing I could think of.
It could be an example of an author assuming a general audience already knows the insider information but then I don't know who the target audience really was. This is the kind of thing that probably should have been spelled out in the introduction, with a link to something like this:
That is poor design for sure.