* Compilation is a ton faster on an M1 and with a non-default linker. Compilation from scratch (including all dependencies) took around 10 minutes for me last time I tried; compilation of the main game is much faster (I think in the ~ 1 minute range, which is more than acceptable if you're not doing something sensitive like animation work.). Obviously, not everyone has an M1, but it's hardly a dealbreaker if you've got a machine designed for development.
* The developer in your video is changing a line in veloren-common, a "root" crate that leads to a bunch of other stuff recompiling. The vast majority of changes are in leaf crates, which compile much faster. For animations, in particular (which require quick feedback) we have a separate compilation unit that compiles on the order of seconds and can be configured to be dynamically linked to the main game, so they can get pretty much instant feedback. For as many kinds of assets and data as possible, we also push it out to configuration files with hot reloading, so most people working on models, item and color tweaks, etc. don't have to wait for compilation at all and can just save their files.
* Many games written in C++ also take ages to compile. Rust isn't unique in that regard. Clearly, it hasn't stopped Veloren's development (I can't think of anyone who quit development because of the compile times, though there's a lot of grumbling). In fact, I'd venture to say that Veloren has had some of the most developers and fastest development of any 3D open source game I'm aware of, regardless of language.
* No major developer I'm aware of announced using Rust for games 5 years ago. What are you talking about? If you mean the Chucklefish title, that had nothing to do with compile times. As far as I know, the game companies using Rust right now are mostly using it for tooling.
* The file you linked is the equivalent of yarn.lock, Cargo.toml is the actual dependency file. Dependencies do not need to be recompiled each time you compile Veloren, only the first time. Additionally, most dependencies compile pretty quickly and parallelize well. There are a handful of dependencies (the procedural macro ones in particular) that take a huge percentage of the overall compile time and/or act as bottlenecks, which is tolerated because they are extremely useful.
Veloren could optimize more aggressively for compile time, if the project was so inclined. A lot of that compile time is spent on generated code from macros like serde. Veloren also deliberately tends to use very large crates rather than trying to split everything into very small compilation units (some of them have been split up to improve compile times, but not too much). The project's perspective is that benefits of using those libraries (which greatly simplify development) and having fewer crates (which makes it much easier to avoid exposing internal APIs to get anything done) far outweigh the compile time costs, but not every project takes that approach and there are a lot of games that compile much faster than Veloren. It's really not a fundamental limitation of the language.