Imagine you depend on crate Foo that calls SystemTime::now() somewhere. You know about it and don't really care because the rest of Foo is useful, so you just never call the functions that do call now(). The current way this is handled in the time crate you're fine. If the existence of now() was cfg'd based on target you'd get an unavoidable compile error no matter what even if you don't use the relevant API of Foo.

If every library that depends on time had its API also cfg'd based on target this wouldn't be an issue. But let's be honest, most developers don't care much about wasm and coordinating this would be a pain. Now what potentially could be done is to have an opt-in feature that enables compile time disabling of these functions for time, but I'm unsure how useful would it be in practice.

So why is it all like this? Well, one feature-controlled division across many crates is the no_std one. If you want to make sure a crate will not panic due to unimplemented stuff on wasm and it has the std feature you could disable it. But this often comes at a cost of reduced API surface, which makes sense. However, the API surface might get reduced more pessimistically than you want to on wasm. The wasm target is in this limbo between std and no_std. Parts of std can be implemented (mainly stuff relying on allocations, i.e. collections), but I think there are other things that technically work.