I'm not sure—I think it's more, in this case, that Rust assumes the developers learning about it have specific goals: namely, to evaluate Rust vs. C/C++. So every resource that teaches Rust couches the discussion in terms of justifying why the particular design being presented is better (from the Rust maintainers' perspective) when compared to designs in existing languages, even if it makes other sacrifices to be such.

I would contrast this to e.g. the Erlang documentation. Erlang/OTP is a great system, and it's well-documented... but the documentation doesn't actually go into the "why" of various choices (e.g. why the BEAM has a module table with exactly two slots per key; why binaries are shared at ≥64 bytes; why clusters are fully connected; etc.)

But I think this makes sense, given the differing approach: unlike Rust, the Erlang/OTP platform is trying to facilitate an abstraction where you just write high-level declarative-ish code, and then improvements to the platform will make that code perform better over time.

Rust documents its decisions because it expects you to be someone who wants to know those things in order to make precisely those decisions (except you're choosing a systems language, rather than designing one.) Erlang leaves most of its internal implementation as a black box, because it expects you to treat it as a black box and derive advantages (in e.g. maintainability) from doing so.