I agree that this would be a sensible approach. It always rubbed me the wrong way that we were trying to cram the whole wiki on a single wiki page. Now I have a technical explanation for why that felt wrong to me.
One of the concerns raised on the talk page was that, unlike the wiki’s own 404 pages, taglists can’t fall back to data item descriptions and images because taginfo intentionally does not integrate with data items. This is not a problem for the English version of the page, but some language communities have prioritized maintaining data items over the full-fledged articles that taginfo scrapes.
As a completely different approach, I suggest taking a step back and considering the main audience of this page: less experienced mappers who are unfamiliar with the wiki’s organization of tagging pages by raw key, who find it more intuitive to search by lay terminology (the built-in search engine is little help here). This is the same audience whom iD’s presets are designed for, so why not make a standalone tag browser based on the same presets that points to the relevant documentation on the wiki?
Conceptually, this tool would be closer to “How to map a” than “Map features”, but I think that’s closer to what most people use the latter page for anyways. The id-tagging-schema project has the advantage that it already collects names of features in each language, not just descriptions, and images can vary by country, not just by language.
As it happens, many of the cuisines have top-level presets, so you’d be able to search for “Japanese” and get “Japanese Restaurant”, leading you to cuisine=japanese.