I must admit that I still write pseudo-C89 code (not fully C99-compliant) mainly because of Microsoft. I lean heavily on MSVC for the Windows side and they're still not fully C99-compliant, instead placing the bulk of their focus on C++17 and onwards.
On top of that I'm working on C SDKs against which a lot of plugin developers use MSVC for their plugin development, and some still MSVC 2010. So there are still popular compilers being widely-used on platforms not so exotic (unless you consider Windows exotic) that don't even fully implement C99 yet. When you target wide compatibility with the biggest range of compilers (which is one of the main reasons the SDK is written in C and not C++), there's still a number of them being widely used (at least MSVC) which are behind on the times when it comes to C support. It's almost been a couple of decades since C99 and we still don't have VLAs, e.g., in MSVC AFAIK (haven't checked up on MSVC 2017 yet but given Microsoft's stance on C, I doubt it is much more compliant with C99).
And so there are still unfortunately new compilers that are actually quite good with good optimizers and debuggers that are still not even fully C99-compliant. Of course if it wasn't for this, I'd be jumping all over C11.
Besides source compatibility with plugins and MSVC, there's also interop with other languages. Some other languages use the SDK through an FFI, and some of those FFIs only understand C89. They might not understand
_Bool as a simple example when importing functions from a dylib and only understand, say,
Yes, the argument in favor is portability but the question is if there
are actually non-hypothetical systems which can only use a C89
compiler but are compiling new distributions of software. i.e. If I
was starting a new C project, how would I decide if adhering to C89
could increase the number of potential users?
Just noticed this one but kind of echoing
Blrfl, the productivity gain by using C99 and C11 isn't so enormous in my case while losing the ability to allow people to write their plugins in MSVC could be a huge cost (especially since the product I work on has the largest market share, by far, on the Windows side and the average user often purchases and downloads many third party plugins). The kind of product I work on is almost halfway between a development environment for programmers/scripters and a user-end product for artists, since so many people want to develop new things on top of it to allow new capabilities and achieve special effects of a kind people haven't seen yet. So in my case it was actually quite a simple decision to favor C89 at least for the SDK.
I suppose you have to kind of look at the compilers around you and try to figure out your target demographic. If you aren't developing a plugin architecture for Windows or doing any embedded programming or trying to build a software development kit that can be used by the widest range of compilers and languages out there, then it certainly makes things easier to reach for C99+ right away. Also maybe consider how much of a productivity boost you get form C99 onwards. I don't benefit that much from things like VLAs since I rely on simple enough ways to use the stack when the data fits and heap otherwise.
But there are a whole lot of things out there lagging behind from popular compilers like MSVC to FFI's in other languages which are cool in the sense that they can import and call C functions directly from a dylib, but might also be a bit behind on the times. So there's a lot more practical business things to consider, depending on your domain, than simply favoring older and standardized for some kind of aesthetic.