It's easy to imagine that a "done" crate will become sub-optimal after a certain time. It can be new language idioms, bug fixes to compiler may make crate uncompilable, an upstream dependency may break and influence downstream code, etc.
With the current policy after maintainer disappearance crates are left to rot for eternity, which I don't think is healthy for the ecosystem in a long run.
This problem can be easily solved by restricting versions which can be published after crate transfer, i.e. the reciever will not be able to publish patch/minor updates to existing crate versions, so cargo update will not pull versions managed by a new owner without manually editing Cargo.toml. This was discussed briefly in my proposal.
No, it does not. crates.io team only uses it for crates with malicious code and potentially for complying with trademark complaints, while NPM also uses this right to fight with unhealthy squatting. Python world also sees rotting packages as a problem, see PEP 541.