VLA usage can also be analyzed (e.g. when bounded in a simple way by a function argumen) and then may allow reduced stack usage compared to fixed-size arrays sized for a worst case.
This does not have much to do with my point, but, anyway, basically any C compiler supports them. MSVC does not, but it also does not support a recent standard so you can not use MSVC to compile C, just some outdated subset.
Pedantically, yes VLAs are a mandatory part of C99 (only). Practically, there has been some resistance so they were reverted to optional in later standards (in C11/17, the whole thing is optional; in C23, variably modified array types are mandatory but the ability to allocate arrays of such types on the stack is not). In any case, MSVC is quite a bad benchmark as far as C (not C++) standards conformance goes—it’s been quite some time since Sutter’s (in)famous post[1] and things have improved, but not to the point that I’d believe C to be a priority for Microsoft.
(Note MSVC has alloca—and Microsoft’s own libraries in the past have done unwise things with it—so the safety argument for the lack of support does not fly.
I’ve thrown all my projects i have written in c for posix systems in the last 15 years against msvc and had only one project which had an issue. Because a dep used VLAs.
As far as I have been told, they were not made optional because of any issues with VLAs (which exist also in many other languages, including Ada) but because adoption of C99 was slow, so some parts were made optional in C11. Later VLAs were criticized for enabling stack clashing attacks that jump the guard page, but this also sometimes possible without VLAs and the real fix for this was compilers implementing stack probing. It is still bad when attacks control the size which should be avoided (and there is -Wvla-larger-than=)