That doesn't matter if features you're able to used are gated on the standard you use. If the standard you choose is based on what your target platforms 'support': no inline for you.
It seems weird to decide that you won't use features because they are in a public standard that your target platform doesn't support, even though your target platform fully supports those features themselves.
I could understand the concern if it was about portability to other target platforms, or keeping the option of doing so. But in that case, the public standard your current target supports is irrelevant.
It happens. Imagine you decide on the MS-compatible bits C99, then the team naturally picks up new people and loses the ones who made the decision. Eventually, people will know the standard is C99 from the build system but not the reason behind the decision.
So they add a feature not supported by MSVC and don't learn that it doesn't work until someone else tries to build on Windows.
If you choose to use features based on whether they work or not, you don't need to choose a standard at all. But that loses you all of the guarantees a standard provides.
Although inline was added in C99, it was already an extremely widely supported extension in mainstream compilers, even since the C89 days, when we just called it "ANSI C".
MSVC has supported inline for a long time, long before it started supporting other C99 features.