You're right in that several communities do that in one way or another. We're certainly not going to say it's outright evil. We've even talked about making a facsimile much like you're describing. What we have said, in a handful of places, is that navboxes in general are not a portable idea and there are other ways to achieve the same navigation. We've come to the conclusion, after years and years of thinking on how to do this right, that the concept of a navbox itself is vestigial; that's why we're not in active development of a portable element to replace it. Early efforts you've mentioned are from before I joined FANDOM staff and are not representative of our current mindset.

Namely, navboxes are fundamentally disconnected lists that extrinsically (not intrinsically) take one's perspective out of the article, and identify the article as being a member of a group. If that group has an order (such as an episode in a season), defining the position in that order is a matter of declaring the relationship on either side (previous and next). If there's not an explicit order (like a list of characters), that's a Category. If you want to add organization inside the category (like Main Characters in credit order), Categories can carry content as well to show such a list. Alternate page versions (like Canon / Legends) tend to be navigation best done by icons (and represent an exception to the page header customization policy). Subpages (like Transcript & Gallery) can be shown in an infobox navigation tag. The big question is really: "Does this link define a static (<navigation>) or data-property (<data>) relationship between this article and the target; if it's not a strong relationship either way should it even be linked to?" 

There are exceptions to all of that, which is when navboxes are appropriate; and you can make them out of tables and classify them appropriately. We'd even appreciate a note on why existing approaches I've named don't work for you, which may guide product development if there's a particularly interesting use-case. But in general, we keep finding reasons to integrate the traditional uses of navboxes in more engaging and data-friendly ways.

I mentioned Thread:2508 because I found it from this wiki's header navigation, which gives it an air of import regardless of who were involved in that thread. The dates on the latest reply do suggest it may not representative of any current mindset, but being on the navigation makes it more referencable/discoverable than anything else on the wiki that might be more relevant.

Assuming I do classify the template as a navibox so it won't get displayed in mercury at all (and assuming the wiki I contribute to is going to continue using naviboxes on articles for desktop visitors), is there any benefit or drawback of implementing the navibox by hacking the portable infobox into a navibox, compared to the traditional wikitable implementation?

Understood. I'll address that soon. We haven't updated that navigation in a while.

There's not a significant drawback that I can think of other than some potential oddity in Community Apps. In terms of benefit, it might be slightly faster and will allow you to use themes (though you can do that anyway with tables and clever CSS).

Thanks.

You mentioned that "navboxes are fundamentally disconnected lists that extrinsically (not intrinsically) take one's perspective out of the article", the same can be argued about MediaWiki:Wiki-navigation. Setting aside the layout presentation, the primary difference between MediaWiki:Wiki-navigation and typical navboxes is that

• navboxes are placed at the "footer" of the article instead of the header
• links in the navboxes are contextual to a/the subtopic or area that covers the article (which the visitor just presumably finished reading because it's in the footer).

While it is true that most links in the navbox would be available by drilling down (and/or up) the category tree of one of the categories the article belongs to, it should also be true that any article/category link available in MediaWiki:Wiki-navigation is presumably available by drilling down from Category:Browse and arguably should also be linked to from the main page. Having the header/footer navigation allows us more control in terms of exposing notable content. I would also argue having footer navigation be contextually relevant to the article has a lot more value than a generic navigation common to the entire wiki.

So, I'm not so much making an argument for "naviboxes" specifically, but I think "footer navigation that can be contextually customized/specified per article" would be something that is great to have even for mercury. MediaWiki:Wiki-navigation is a list that is up to three layers deep. Most typical naviboxes are also three-layer-deep lists (header being the first item of the list). Thus conceptually we could have a "article-specific footer navigation system" that is specified as wikilists much like MediaWiki:Wiki-navigation, and mercury can turn it into a footer menu while desktop skins displays it as a navibox.

Wiki navigation is not content, though. That's a significant difference. It's also consistent, community-wide.

I don't dispute the first part of that (category drill-down), and that's the premise of Mobile Main Page. The second part is a little fuzzier. Wiki-wide navigation drilldown should also, in theory, from Category:Browse; in practice, not all wikis do this (or use Category:Browse at all). Further, drill-down to any given page is not how most readers navigate in the first place. The most common behavior (by far) is search.

I don't disagree at all with you about surfacing contextually relevant links. I'm disagreeing that navboxes are the obvious solution. In addition to being a difficult pattern on mobile devices, the usability testing shows that they come off as more noise than signal beyond a few links. And that makes sense, for the same reason that restaurants break up menus into groups of no more than a few items (and add more data to those items to describe them). By that rationale, it's really not about having the cluster of links at all: it's about showing enough relevant context for why a reader should follow those links. Quality and context trump quantity. Having a list of links without context is noisy.

While -- once again -- I'm not disagreeing with you on principle, testing shows that people just don't use the footer for that on mobile. Adding three-layer-deep lists to an already minimalist-interface is just too many taps; users won't traverse it. They might do one tap per page to get to other pages, but digging / drilling down is too much work.

I think we disagree on what we have disagreements about q-:

What is "obvious" could be wrong or not optimal at all, and in that sense, I argue that the existing proliferation of naviboxes on various wikis is data suggesting many wiki contributors/admins find it the "obvious" method of solving the issue of content discovery/navigation (at least in the desktop experience).

It was "obvious" to a lot of people, thousands of years ago, that the earth is flat d-:

Btw, is there data on how well "Portal" pages perform? I really only see Wikipedia having them. Maybe a link to a portal page at the bottom of the article might work sufficiently well for the mobile experience? Would love to know if any non-wikipedia wikis tried it and how well it worked for them.

There's not strong data AFAIK. Only a handful of communities use them, but they're a concept I'm pretty interested in. Wookiepedia uses them. I think Memory Alpha does, too. DC tried them but were not largely successful.