What I was trying to say was more generally “actual mapping > discussions about tagging”. If it’s largely the same group of people doing both (and to at least some extent it is) then time spent doing the latter will remove time available for the former.
As an example where I’m guilty of exactly this - I’ve just written this reply rather than getting started on adding major regional cycle routes such as the National Byway and WYCR to here 
That is correct. It’s the safest way to process nested (and unnested) route relations right now. And as you pointed out correctly, the types of the members will easily and reliably tell if a route is nested or not. The route type simply doesn’t matter. Both is fine. No need to eradicate one tagging method or the other. Any QA tool or editor that relies on the route type is ignoring existing realities.
When using type=superroute, you do those data users a favour who don’t know about nested relations: they don’t need to scan through all of the members before finding out that there are no ways. But it is a relatively minor advantage.
If type=superroute ceases to exist, there is one test condition less in my code. There is even less gain to be had.
I find it helpful as a mapper to be immediately able to see when something is just a relation collection (and thus can be safely ignored while working on route geometries) but won’t change tagging if others think differently.
There are more pertinent problems with nested relations: there is no reliable way to tell if a relation that a member of another relation is only a stage of a larger nested route or also exists independently. So strictly speaking, I’d be more interested in a type=subroute type. But there are other solutions for this surfacing now.
Yes, I agree that there is no significant technical advantage either way for existing data consumers, and a minimal advantage in intuitiveness for new data consumers. In light of that, I would contend that the more significant benefit is alignment with a lay understanding of the concept of a route.
It’s an accident of history that we model route legs, stages, or directions as routes themselves. I’m not especially inclined to turn over that stone, because of the disruption it would cause. But it is confusing when some routes are tagged differently than other routes in the same network, even concurrent routes, just because of how granularity we’ve mapped them. For example, I’ve noticed hesitation to tag the superroute relation with tags that should apply to the whole route; there’s no such inhibition when the parent route is a route.
There’s currently a discussion about adding a preset to iD for type=superroute. We’ve done so for type=route_master but it hasn’t done much to help mappers know what to do with them. As a minor step, I’ve considered requesting that we name these presets “Route Broken Down By Legs” and “Route Broken Down by Variants”, respectively, but iD could just as well say “By Legs” about a route superrelation.
Anyhow, the sense I’m getting in these discussions is that some mappers have gravitated toward type=superroute because of a more tenuous relationship between the member relations – strongly related by geography but not as much by other details. Where I come from, node networks are almost unheard of, and these days long-distance routes are coordinated to such an extent that a renderer could almost certainly get away with ignoring the different signs that states use for their legs of the same route.
If type=superroute is the best way to communicate a more tenuous relationship with regard to EuroVelo routes, then I won’t push any further for consistency, but we have a lot of work to do to add carveouts for superroute and explain the differences in documentation.