Upcasting is not (Rust) compiler jargon, it's OOP jargon
I don't believe multi-trait objects that are never upcasted can be insulated from the implications of supporting upcasts. This is because, again, there might be code anywhere in the application that performs an upcast, so all multi trait objects need to be represented in whatever way is needed for upcasts.
With that in mind, supporting upcasts potentially has a huge cost. It's possible that we'll pick the "N vtable pointers" approach for other reasons, in that case upcasting is cheap to add. But these decisions are interwined.
Hm, good point about proxy impls on trait objects. However, in my experience trait objects in interfaces (including interfaces within a crate) are somewhat common, despite the popularity of generics, especially in "business logic" crates as opposed to foundational crates that provide data structures, algorithms, serialization, etc.
Are you suggesting we restrict which upcasts people can do? That, too would be a valid language design decision informed by what is and isn't implementable efficiently.