It's not counter-intuitive and not ironic. If you read rules from Google's C++ style guide you would see almost the same rules as in any Rust program. And even if you go back and look on what it was saying years ago you would see the following:
Generally speaking, we prefer that we design code with clear object ownership. The clearest object ownership is obtained by using an object directly as a field or local variable, without using pointers at all. On the other extreme, by their very definition, reference counted pointers are owned by nobody. The problem with this design is that it is easy to create circular references or other strange conditions that cause an object to never be deleted. It is also slow to perform atomic operations every time a value is copied or assigned.
Although they are not recommended, reference counted pointers are sometimes the simplest and most elegant way to solve a problem.
That's year 2008, when Rust was just a a hobby project, not endorsed by Mozilla yet!
Yes. And while sometimes you do that for efficiency it's always a hassle. That's why people in C end up with the exact same rules as Rust (+ few small exceptions where we may cheat a tiny bit).
I guess it's because most Rust developers (at least initially) were C++ users. Without GC you can not make memory management S.E.P.. You have to deal with ownership immediately and the consequences hit you immediately.
You can create complicated constructs which would lead to hours of debugging, but if you work with huge codebases sooner or later you stop doing that: tiny increase in efficiency is just not compensated by hours of debugging.
Thus usually you try to use unique_ptr as much as possible and have “chain-of-trust” which goes to the main, ultimately.