Back in the time we only supported Windows Desktop it was possible to rely on Microsoft Store to deliver a compatible VCLibs package to ensure the required runtime libraries would always be present in the target system.
We cannot rely on that mechanism on Windows Server. Thus we should avoid linking against them dynamically, since CMake 3.15 onwards offers way to do it statically.
The recipe can be applied to any recent Flutter app targeting Windows to avoid the need for shipping msvcp140.dll, vcruntime140.dll and vcruntime140_1.dll libraries. That can be handy for deployment under certain situations, but increases the overall app size since every native plugin (and the runner binary) will be affected by this option (a lot of binary code will be duplicated).
The size increase is irrelevant for the WSL case, because our main size constraint is orders of magnitude bigger than the Flutter-produced binaries.
Relevant documentation about this topic can be found in MS FAQ about Runtime libs, CMake CMP0091 policy and MSVC_RUNTIME_LIBRARY property
Notice the usage of generator expressions in the snippet "MultiThreaded$<$<CONFIG:Debug>:DebugDLL>"
to ensure we still link against the debug runtime DLL's in debug builds, otherwise those builds would be much bigger and likely slower than they currently are.