I don’t dispute that it should be possible to nest route relations in other relations. However, I’m not sure why this requires a special relation type. You’re expecting the “superroute” to be homogeneous, consisting of only route relations as members that collectively form a single linear geometry. Certainly, a roadway should always be a member of the most specific relation available. However, I don’t think the requirement to be homogeneous or connected would be valid for all or even most nested route relation situations in the U.S.
In my experience, the most common reason to map two route relations and group them together is that a route traverses both sides of a dual carriageway. Whether the child route relations touch depends on whether the dual carriageway becomes a single carriageway at any point. The JOSM validation rule could still be useful, but not in every case.
For example, this super-duper relation represents a route looping around Washington, D.C., entirely on dual and quad carriageways. This is technically a collection of three discrete routes, but no one thinks of it that way in practice, especially since one of them is only 580 feet (177 meters) long in the middle of a bridge, as wide as it is long. Some of the bottom-level route relations touch, but not all of them, because the clockwise and counterclockwise carriageways never meet. (The superrelations in this structure are divided by state, whereas a different route on the same road has superrelations for the clockwise and counterclockwise directions instead, all based on the signs.)
Should these super-duper relations be tagged type=superduperroute? Maybe, but I don’t see the point of making up extra words for things that aren’t that super-duper special. A separate relation type for streets would seem to me like the higher priority. I’m fairly confident most data consumers would care more about distinguishing those from routes based on tags, since route superrelations are already identifiable by their members.