A couple examples:
Rust requires references to memory to be visible at compile time. If you use direct DMA for I/O then the silicon holds mutable memory references at runtime that are not visible in code at compile time. In C++ you can make ownership objects (in the vein of unique_ptr) that automagically track the lifetime of DMA references. Exposing most of your address space to DMA is not optional in databases if you care about performance. DMA has other nuances as well e.g. it can modify memory that is not part of the object you care about and which might be "owned" by someone else.
There are safety models wherein it is provably safe, and optimal code-wise, for multiple mutable references to the same object to coexist at runtime. Modern databases often use schedule-based safety, which dynamically reorders operations on references at a fine-grained level, for performance reasons, and which guarantee correctness of the aggregate execution graph without using locks. This wasn't common a decade ago but it is today. A developer can grab all the mutable references they need to objects, knowing that the execution scheduler can see through and arbitrate any potential conflicts. (This is a sophisticated reimagining of the old "deadlock-free" locking structures in databases without the locks, which didn't prevent deadlocks per se but transparently detect and resolve them.)
You can make all of this work in Rust by using a lot of "unsafe" and inelegant data structure workarounds but it voids most of the safety benefits of Rust and requires more complex code.