One common use case for DLLs in gamedev is for code hotloading. You can just recompile your game DLL and unload / reload the library, patch up some globals and vtable pointers and voila, your game logic has been updated without restarting the game. And all that you get just writing normal C++.
This is only for development. Shipping builds will usually statically link everything.
But, as far as I understand, the boundary layer has to still be C (the side that loads DLLs and stuff), because of the natural limitations of templated languages and linkers.
And as soon as you change any interface you'd need to recompile more parts of the code. The same can be applied with Rust using dylib. At the end, the glue code always end up being C.
On any given compiler you can make C++ have a stable ABI. You can even do this commonly in practice across compiler versions, even, the standard library typically tries to achieve this.
It's easier to have a long term cross version cross compiler stable C ABI, but if you're talking a single toolchain that simplifies the problem tremendously and you can absolutely do that with C++ in practice at that point
If you don't care about the ABI being stable then you can use a Rust-based ABI, but you're essentially just static linking everything then. Not sure how that works out for the game developers.