Counter to this example is enum variant types (and even more so types as enum variants, though that has far less support).
If/when Type::Array is a type of its own, I expect new code to have a lot less Type::Array(struct ArrayType { type, length }) and more Type::Array { type, length }. Only time will tell, though.
And an irrefutable pattern type elision will still be useful for other cases of nested structs, even if usage of newtype variants decreases.
variant type vs. type variant
These aren't the point of the thread, but do have an impact on the usage of newtype variants.
"Enum Variant Types" is where Enum::Variant is a proper refinement type of Enum. A value of type Enum::Variant is effectively a value of type Enum that is known to be the Variant variant.
"Types as Enum Variants" is effectively a new kind of enum variant which is a structural (rather than nominal) newtype variant. Ultimately it boils down to a newtype variant with extra sugar, notably in that you pattern match it as Type { .. } rather than Enum::Type(Type { .. }).
It's worth noting that being able to elide the type name for irrefutable struct patterns would all but subsume the benefits of types as enum variants, especially when enum variant types are a thing.