Thanks! And I have not seen any teams doing this kind of thing either.
Another tidbit: The developer pairs were responsible for writing both the production code and associated automated tests for the production code. We had no 'QA' / test developers. All code would be reviewed by a third developer prior to check-in. However, at one stage we tried developing all the test code in a high level scripting language with the idea that it would be faster to write the tests and need less lines of test source code. However, because we did several projects like this, we noticed that there was no advantage to writing tests in a scripting language. The ratio of production C source lines to test source lines was about the same whether the test source code was written in C or a scripting language. Further, there was an advantage to writing the tests in C because they ran much faster. We had some tens of thousands of tests and all of them could compile and run in under two minutes total, and that includes compiling three version of the sources and running the tests on each one; production, debug, and code coverage builds. Because the entire test cycle was so fast then developers could do 'merciless refactoring'.
As another software developer working in the "embedded systems" industry, I can tell you that using C like that is not unique. The companies I have worked for and several of my friends have worked for all use C similarly. Sometimes we do use the dangerous features of C. When we do, additional reviews are done to ensure the use is both sufficiently justified and properly done.
Unfortunely your case is the exception that confirms the rule.
I never saw a company using C like that.
On my case the teams used to be composed from circa 30 developers, scattered around multiple consulting companies with high attrition.