The structure and class names? Probably not, the structure looks kinda verbose, but not unreasonable if you imagine them using an off-the-shelf HTML/CSS library for the site.
https://paste.pound-python.org/show/L3Yhf3vJ8rMuiO4OWLOm/
That looks pretty obfuscated to me.
I'm guessing what you're seeing is the html that's generated from that somehow. Or maybe it's serving up different html to different clients/IPs?
Maybe someone who's more familiar with web development could explain.
My best guess is that it's picking up the wget user-agent and serving up some bot counter-measures?
Then I tried wget and got the same weird obfuscated stuff I pasted above, and got it again when I wgot it again.
Right now, we're running the whole response through something like an optimizing compiler stack (Webpack, with lots of plugins and some custom modules). It renames everything to the shortest possible name, eliminates code that will never execute, inlines CSS into the <head> and <body> to reduce HTTP requests, splits the code into large bundles that can be cached forever and a small bundle that will be updated nearly every workday, stuff like that.
I'm afraid we're at the point now where a modern HTML response requires advanced tools in order to make it legible to a human. For that, I apologize, no sarc, we are aware of the loss of culture that is happening. There is some pushback happening, in the form a ruthless minimalism (plain HTML, no css, no JS), but good luck demonstrating the beauty of that to the UX team.
If it's any consolation, these advanced tools are built into FF and Chrome; just right click, inspect element, and look for associated JS handlers. The browser can clean up the code formatting for you, although the names will still be arbitrary. Set a breakpoint on an interesting statement, trigger (or manually fire) the action you followed to get there, and explore the values that are in scope at that point. Watching the values change will often tell you more than reading the code itself, when the names are meaningless.
As for the inconsistency mentioned by my sibling, that sounds a little broken. One of the things we do with the Webpack stack, is specialize the code for known browsers, by eliminating the browser-specific stuff that isn't needed for the current visitor; w3m and wget are not high priority targets :/