Yes, consoles, phones, and web are the hard ones to support due to a lack of JIT support. That's going to take some time to resolve. Especially since Native AOT is much more restrictive than IL2CPP.
IMO Burst was a mistake. C# running under .NET runs significantly faster without needing to write code differently. And if you need to go even faster you can write code differently to make use of modern C# features to boost performance rather than relying on a secondary compiler that only allows a subset of C#.
On the contrary, I was there when game devs took some convincing that C / Object Pascal compilers were getting good enough over Assembly, even if some inline Assembly was still required in hot paths.
When the whole C vs C++ quality of code generation debates started, that were the genesis for Matt Goldbolt while still working at the games industry, to have created Compiler Explorer as means to shutdown discussions regarding C++'s adoption, which nonethless persist to this day, especially in the Handmade community.
Burst was necessary, to have industry legends like Mike Acton come and join Unity, despite their strong opinions against C++.
Burst is an impressive piece of tech but it really only exists because both Mono and IL2CPP are shockingly slow. Mike Acton worked under DOTS which is the only place you'd actually see the benefits of Burst. The 99% (or more) of Unity games not using DOTS can barely use it because of its limitations. They are left to suffer with poor performance.
If you haven't seen it before you should check out the kind of code IL2CPP generates. Literally starts almost every function with a branch.
IMO Burst was a mistake. C# running under .NET runs significantly faster without needing to write code differently. And if you need to go even faster you can write code differently to make use of modern C# features to boost performance rather than relying on a secondary compiler that only allows a subset of C#.