There's a reason they offer "download and run this .exe" on Windows and "download and run this .sh" on POSIX platforms.
...plus, as they mention in the tiny "other installation methods" link, none of the distro packages are official and people have a nasty habit of coming to you for support even if you didn't point them at the downstream-patched distro package they found.
Given how much distro packagers have tried to contort Rust to fit into their pre-existing `.so`-centric packaging system, I can see why Rust upstream would want to downplay that option to avoid headaches.
Let's compare what some other supplementary package managers tell people to do:
As for "and also not that Rust's design makes it more difficult to package", give https://blogs.gentoo.org/mgorny/2012/08/20/the-impact-of-cxx... a read.
TL;DR: It's not a Rust thing. C++ suffers from the same problem when you use templates in your APIs... it just emits a .so file with no contents if you expose only templated APIs. It's fundamentally a problem of "Unless you're willing to spend Swift-level engineering money and still accept compromises Rust and C++ can't afford, dynamic linking in the presence of monomorphic generics is a problem even research languages haven't solved".
...same as the warts in async Rust. What you're seeing is a cutting-edge language slamming up against the limitations of what cutting-edge programming language research has figured out.
At least, with Rust, you've still got the dependency tracking and automatic RUSTSEC advisory tooling you don't get with header-only C libraries.