The short answer is that it's quite common not to constraint structs but just the implementations that work with them.

You don't notice as much normally as most structs do not expose their internals and the constructors are often constrained.

You have no benefits from containing this.

No of the problems come from this not being constrained on PartialOrd. Instead they are related to other things like the usability benefit of range construction not being fallible (which is why we can't have a start <= end constraint in the type).

Some things could be done differently by constraining the type to always be an integer, but expect `constains` now not needing a reference non of the thinks the article complained about would be different just by constraining it to an integer. In practice many of it's method are anyway only defined for some Range types like you can only use `Range<usize>` for slicing.

As others have said you don't often put constraints on types in struct definitions. Most of the time if you do it is for using associated types to simplify generics.

The reason why constraints on structs isn't a good API design is because it limits future API design scope unnecessarily. In this case, maybe you want to reuse the Range syntax as part of a DSL?