Never traits

Sort of, but not exactly. I believe this confusion arises from conflating traits with types.

Instances of ! can be coerced into arbitrary types. So if you're coming from another language, it might seem intuitive to assume that this means ! should implement all traits. But it is important to remember that traits are not types.

If types are nouns, traits are adjectives. Or to put it another way, a trait specifies a family or category of types, not a type in its own right. This differs significantly from interfaces in languages that support them (Go, Java, etc.), where you can simply treat an interface as if it is a type for all purposes (except for calling the nonexistent constructor). You can turn a trait into a type by prefixing it with the keywords dyn or impl, but those are not the same as the trait itself, and have important differences in their semantics:

* dyn Trait is only compatible with some traits. It is also dynamically sized and must exist behind a pointer, in a language with manual memory management and no GC. Either of those restrictions in isolation would be far too annoying for dyn Trait to be the type-level equivalent of Trait (but early Rust did try to make this work). This also implies the use of a vtable for dynamic dispatch (hence the name "dyn"), and the incompatibility stems from methods that do things like passing Self by value, not having a receiver at all, having type parameters, etc. (none of which can be dynamically dispatched in Rust).
* impl Trait is compatible with all traits, but it's a form of generics. Generics must be tied to some function or other context that tells the compiler how they should be monomorphized. So you can't treat it as a general-purpose type-level equivalent of Trait, because in non-generic contexts, this would make no sense. In a generic context, impl Trait should be read as "some type which implements Trait, but I'm not going to tell you what type it is."

The Default trait, in particular, is the Rust equivalent of what C++ calls "having a default constructor." It is not a type, nor does it have a type-level equivalent in most languages.