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.