Most online debates are filled with illogical opinions on theoretical issues. You get people on this site complaining that they have to spend money on a catalytic converter because it's not required for the car to run and only prevents other people from getting cancer.
For proper bounds checking in C you first need to communicate the "bounds" to be "checked" to all the places where it matters, just a pointer isn't enough. Unfortunately many old-school C APIs (including the stdlib) often don't pass pointer-size pairs around, but just pointers (and IMHO the biggest problem in the C world is not so much the language, but outdated APIs like the C stdlib or POSIX which have mostly been designed in the K&R era and which basically "encourage" unsafe usage).
Other then that, I doubt that any reasonably pragmatic and experienced C programmer will ever argue against runtime bounds checking from a performance point of view. Even in hot loops one can usually move the bounds checking to a place outside the loop.
My experience in some gamedev and embedded development circles is that there are several that will religiously argue against it, without ever having run a profiler to validate their perception of the world.
FWIW, I'm also coming out of the game dev world, and we shipped all our games with (custom) asserts enabled (which includes bounds checking in containers). I did regular performance tests and the enabled asserts were never a big enough performance hit to justify removing them (around 1..3% across an entire frame), the ability to get 'clean' crash reports from out in the wild, triggered by asserts instead of random segfaults was more than worth it (we also had special 'hot path asserts' which were not included in the release builds though, but those were rarely used). The only downside is that the executable gets around 25% bigger (and easier to reverse engineer) because of all the embedded assert-condition strings - but I guess this could have been solved differently (since we were using our own assert macros anyway).
That is what I have been doing since forever, in C and C++ land.
In C++, I kind of always strived to use the higher level abstractions, with support for bounds checking. First the compiler provided frameworks from pre-C++98, then configuring builds so that STL types also bounds check in release.
In C is harder, but a mix of asserts, using TU as if they were modules exposing ADTs (Modula-2/Pascal units style), can also be a way to help mitigate issues. Kudos to the Code Complete book for some of the ideas[0].
However, trying to sell this experience always feels like quixotic in those environments, so kudos for actually doing it.
[0] - "Code Complete. A Practical Handbook of Software Construction"
A lot of people don't care about security but they do care about performance. Some examples: game engines, various solvers, simulations. This stuff runs 24h/day to produce results. A few percent here and there is a huge cost and time penalty, especially that in this kind of code bounds checks and similar have bigger consequences than in your typical CRUD app. Another example is programming for small devices which are not upgraded for years. It just kills user experience if you accumulate tens of milliseconds of performance (and again on those devices the penalty is usually bigger because CPUs are not that smart about prediction).
If you care about security of processing outside input the are many other options (or you can use sanitizers or safe practices in C). For significant part of the C programming world it's just not important though.
This is mostly true. The one exception is when bounds checking prevents the compiler from vectorizing your code. Then you may pay up to a 50% penalty for the innocent looking `if`.