It's easier to translate wasm to another machine code than adding a target to for the compiler as that requires somewhat wider range of knowledge. There's no specific reason they're using wasm other than it being pretty straightforward and platform-agnostic when compared to other assemblies.
The thing is that the browser isn't really an operating system, so to me target_os doesn't feel appropriate either. Further, WASM is a very specific target, while "browser" can mean any binary format supported by any of the browsers (currently only WASM but it might change in 10 years).
There was talk about unifying wasm32 and wasm64 under cfg(wasm), but it was decided against due to the reasons outlined in the issue.
#[cfg(target_arch = "wasm32")] doesn't imply the targeted environment is the browser, it's only commonly used to switch between web-sys and native execution because the rest of the code is generally compatible between targeted platforms (Namely OpenGL).
People use #[cfg(target_arch = "wasm32")] only because the compiler sets it consistently across the entire build and it doesn't have to be passed down the entire dep. chain, but something like a global named "browser" would probably be a better fit.
When using a crate you have to be aware of its limitations (which are hopefully listed in README). A crate that has no #[cfg(unix)] gates might still only work for *nix systems and not on Windows. If a crate targets Switch in the manner you've described and the browser then target_arch isn't enough to switch between them.
You're of course allowed to define your own "browser" feature, but unless there's multiple WASM platforms you're targeting, it's simpler for you and your dependents if you just use #[cfg(target_arch = "wasm32")].
There's crates that target unix but have x11 and wayland features which will likely be replaced with just #[cfg(unix)] once X11 is no longer used by a large majority of people.
When it comes to specificity, you can go as far as #[cfg(all(windows, feature = "win_11", feature = "winui", feature="crescent_moon"))] but unless you need such a specific conjunction of features and you know you'll always use WinUI just #[cfg(windows)] is enough. That same logic applies to "wasm32" in most crates - they target no other WASM platforms.
I'd also like to offer advice when it comes to feature support - make it work for one use case first and then start adding features and feature gates. Writing code with lots of feature gates upfront is very demanding, you'll spread yourself too thin and have to re-write much more code if you go that route.