Nothing about 'zig cc' is related to language semantics, it is entirely a toolchain feature. Language semantics do have some bearing on cross compiler difficulty, but IMHO it's not a major factor, especially within the sorts of languages that Rust and Zig are. The largest factor I can think of (compile-time code execution) exists in both Zig and Rust. It's possible I'm forgetting something, though.
It doesn't exist in Rust because nobody has proposed it or implemented it, simple as that.
I think Zig does cross compilation (ignoring for the moment, projects with C dependencies) better because it comes out-of-the-box with the libraries and headers needed to target a lot of systems. In Rust, you typically get additional toolchains via rustup, whereas Zig works on all of the targets with a single install.
The whole toolchain for Zig, which appears to include complete cross compilation, is less than 40MB compressed[0]. I would hardly call that a "monster download".
I think developers can spare that much space. Besides, storage space is scaling much faster than the number of available targets, so I don't see how this could be "not particularly scalable" unless you either have a weird definition of "target" or predict there's going to be a sudden explosion in the number of targets.
Go also makes cross compilation to any supported target a breeze in the default toolchain download, and it is an incredible convenience for the developer.
The Xcode download, which is the only officially-supported way to develop native apps on macOS and iOS, is 9.8 GB and gets larger with every update. The Windows 10 SDK is 4 GB and likewise is only getting larger. Sure, you can develop some apps with only a subset of the SDK. But, as a language project, do you really want to be in the business of optimizing and subsetting every single OS SDK?
I think a lot of the issue here comes down to targeting server workloads and command-line tools vs. apps using more of the OS libraries. In practice, Go focuses on the former kinds of apps, so shipping all targets is a more viable approach for them. But when you start getting into apps that want to use a larger swath of the platform facilities, then the size of the platform SDKs starts to become an issue.
I see. I'll let the real experts add some insight but I don't think language complexity has much to do with it, considering Rust compiles to an IR first anyway. And I would say Rust has a good cross-compilation story as it is. In 2016 (!) I managed to get Rust to compile my SDL2 game to a mipsel device that used a custom GCC toolchain (http://www.gcw-zero.com/develop)
It doesn't exist in Rust because nobody has proposed it or implemented it, simple as that.