According to the article, this is in large part for security, and a little bit for speed, not for size.

There is a Linus quote in the article: "It generates much more code, and much _slower_ code (and more fragile code),". "generates much more code" means a size difference.

If he had just said what you quoted he would be wrong in the general case.

He actually said it is all those things in comparison to doing fixed allocation. The reason that is relevant is the kernel stack is so small you can only use a VLA when you know in advance the upper bound on the size is small, but if it's small you may as well use the fixed upper bound, and if you do that it is always faster, smaller and less fragile than using a VLA.

He's wrong in the general case, because user land C programmers will replace a VLA with:

    if (!(array = malloc(n * sizeof(array[0]))) fatal("I'm out of memory");

which compared to the VLA generates more code and is slower. In both the VLA and malloc() case if you run out of memory the program will die nice and deterministically (unlike the kernel), but in the malloc() case that will only happen if you remember to do the check whereas in the VLA case the compiler ensures it always happens.

Wasn't removal of VLA also a requirement for building the kernel with clang/llvm ?

Does this mean that mainline now builds with llvm?

Removing VLAs in structs (define a struct type in a function, use variables from the function in an array field's bounds) was a requirement, but "normal" VLAs are supported by clang just fine.