There is a big difference between what Java calls AOT and this. Statically linked hello world in Vala which uses some basic standard library functions is less than a megabyte (most of it taken up by glibc as I couldn't get it to compile with musl). If you assume dynamic linking for core libraries then it is just 15KB.
I have no doubt that the Java world has excellent tech behind the AOT support but the footprint is simply not comparable when you can't even construct a java.lang.String without bringing in the entire JapaneseChronology.
"Now" being the operative word. Vala's quite old; when it came out C# barely existed on Linux. I think these days C# is almost definitely the better choice for whatever you might have used Vala for in the past.
C# on Linux still has some warts, the runtime is massive and most distro-packaged software pulls that in its entirety. (And for extra fun, sometimes multiple versions.) All that overhead sits between your code and GTK, and something like Vala completely sidesteps that hassle.
That said, it only really shines for the "gtk based linux desktop" usecase, for everything else the situation flips around, as you now need to bring your own GTK. Occasionally still worth it embedded, but not much else.
There were a couple of Linux/Un_x desktop applications written in C# back in the day - Tomboy, F-Spot, Banshee, Beagle come to mind. They were pretty good at what they did.
But the GNU/Linux camp was rather hesitant to adopt .Net for fear of Microsoft suing people over patent issues. At least that is my memory of it. People wrote replacements for those apps Tomboy -> gNote, F-Spot -> Shotwell, Banshee -> ???, using Vala.
Now that Microsoft has made .Net open source, the lawsuit threat seems to be gone (at least for the foreseeable future), but I think the ship has sailed.
A bit of a shame really. Gnome development could be nicer with a language with some basic memory safety features and GC, but still generates fast code. Like C#.
There's still/again some C# apps for Linux desktops, like Pinta, but the dotnet sdk experience with it so far has been a lot rockier than with mono back in the days. Performance is great, ergonomics for end users not so much.
There are quite a few issues that make any JVM language difficult to use in scenarios like this one, in particular, lack of high quality and low overhead interop and certain low level features like C structs.
There is also now an option to statically link native libraries into NativeAOT binaries in .NET, and to statically link NAOT-compiled .NET libraries into existing C/C++/Rust binaries.