From those sites:
There is a lot of completely inaccessible ASCII art.
Everything is shown in a plain monospaced font, including tabular data. Emphasis can only be done using asterisks, capital letters or similar.
Images can't be embedded with context, only linked to -- at the end of the document.
Links can't be shown in context, only at the end of a document.
Only ASCII text works.
Gopher, on the other hand, simply only supports textual navigation that is easy to feed to a text-to-speech engine. The developer doesn't need to even think about these issues.
You mentioned tables, but there were many years where people were using tables in HTML for formatting instead of just expressing tabular data. So div tags were added. Now people sometimes use divs to represent tabular data.
Search is a pretty good way to navigate content, and is simple for raw text. An index is an even better way, and is supported quite well by gopher.
Yep, and there are algorithms that try to distinguish between ‘data’ tables versus ‘layout’ tables for precisely that reason. It’s unfortunate that they have to exist, but the web has routed around past mistakes.
Now people sometimes use divs to represent tabular data.
Yes, and that’s wrong and a simple fix. But regardless of whether some ill-informed people do that it’s still no worse than Gopher, and when they get it right it’s a lot better.
Regarding search, that’s great if you have exact keywords for what you’re looking for. Less good if you just want e.g. a list of headers on the page so that you can narrow in on the part that interests you.
Gamefaqs hosts plain-text documents. Some of them are quite long and well-structured. Since there's no intra-document linking like with HTML, newer documents tend to have hashtags in the TOC to make Ctrl-F searching easier.
I'd much rather have intra-document links I can click on. That way, as a document author, I can direct readers to the dedicated "All The Monsters You'll Ever Fight" section from anywhere in the document without adding the string "#monsters" all throughout the document, generating false positives for the Ctrl-F-using reader.
1. harder to implement
2. More error prone.
I myself am quite an old grumpy fart, but I would prefer to browse most web sites as gopher sites. I stumble on way too many sites that would have been more usable to everyone had they just skipped those extra 800kb and kept their page below 30kb.
Let's say we are both on an unreliable wifi connection (perhaps on a train) and want to find the most recently-released entry in the table. Then we want to sort the data by each of the other columns of the table.
I click a heading and navigate to the bottom row of the table and see 2016. Done. Then, whenever I am ready I click each of the other four headings to sort the data again. This exhausts the effort I need to expend in order to get sorted views of the same data. And no network access was required to do this (which is nice for non-trivial table sizes).
With Gopher, what user actions are needed to get the same views of the data? How much effort do these user actions require?
Edit: also, are those user actions discoverable? At least visually Wikipedia's table gives me two arrows and a cursor icon change to make it apparent I can click to change the view of the data. As far as accessibility, there is a "title" attribute with the value "Sort ascending" that I presume would get read by a screen-reader.