While it's true that there are less opportunities to track you through leaky / malicious apps, "dumbphones" remain, well, phones, with data retention laws in almost all countries in the world (and the subsequent leaks / hacks, see the recent Salt typhoon events for a good example) plus extra vulnerabilities due to poorly-developed Operating Systems.
The best I could find was a rough 2.5x speedup of ChaCha8 vs ChaCha20 in the "Too Much Crypto" paper and https://github.com/jedisct1/rust-aegis#benchmarks that benchmarks ChaCha20 and various AES implementations in addition to AEGIS, where it looks like ChaCha8 might be competitive with hardware-accelerated AES on some platforms (AMD) but not others (M1).
Unfortunately, this is comparing apples to oranges because AES-256-GCM is authenticated, so you will need a MAC with ChaCha12 (usually Poly1305) which finally makes ChaCha12 in AEAD mode slower than AES-256-GCM.
But the real question is: What is fast enough?
I believe that between 1 and 2 GB / s per core for an AEAD is fast enough as I/O will be your bottleneck way before that.
This is why I will always favor a ChaCha20/ChaCha12-based AEAD over AES and its many footguns.
2. Rust has improved its compiler performance by >3x in the last 5 years.
3. Rust hasn't gotten any major new language feature in the last 6 years. Most language improvement is improving orthogonality of existing features.
4. Rust has an excellent backwards compatibility story also right from the start. Code/libraries written in 2015 can be still compiled and used together with code from 2025.
5. Rust has a serious backing from all major IDE / editor providers.
6. Rust has integrates easily with other languages and ecosystems. It's easier to call Rust from Python than to call Scala from Python. It's easier and more performant to call C from Rust than to call C from Scala. Things like that. It's sad that Scala even struggled with interoperability with Java; which should theoretically be easy as it is the same platform.
Seriously, doesn't look to me like the same mistakes. It's actually quite opposite.
It's time to shift priorities.
---------
To me the goals are sensible the flagship goals (for 2025H1 for example [1]) are all about DX and focus on downstream devs and their needs (all hands, Rust in the kernel).
The usual problem of "compile times" [2] (usually link times and LLVM throughput and so on) are things that are being worked on, but fundamentally they all can only be solved by caching, incremental compilation, and better developer tooling that are not language problems.
[1] https://rust-lang.github.io/rust-project-goals/2025h1/goals....
[2] https://old.reddit.com/r/rust/comments/1if5wpm/high_hopes_fo...
Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years.
Tooling and the community just can't keep up and the language is very good already that the focus should be on the ecosystem and not language.
But Scala devs are beyond deaf and that's what you get when a programming language is an ongoing research project on which many students and professors depend.
It's not enough to say "if we stop developing new features the language will die" when there's 0 evidence by it and a huge fatigue towards the relentless development coming from most of the community.
Edit: It focuses too much on the language instead of the ecosystem.