It's possible that the reason there was no C for TPF is similar to why C arrived very, very late to CICS on S/390 (or z architecture).
Namely, C standard library was not reentrant safe, with considerable global variables et al - and the code on CICS (and I suspect TPF) had to be fully reentrant because it effectively ran inside green threads.
So, unless IBM wanted to advertise C that wouldn't contain standard standard library, modules written in C would be possibly dangerously playing with global side effects. Relatively recently this was solved by common runtime component whose name eludes me at this time, which underlies standard run times for C/C++ and I think Java, at least inside CICS
Due to my experience with C on Unix, I once did a contract to program in C on IBM/370 systems. It was extremely painful. Especially editing C code on 3270 terminal. C on 370 was driven by marketing to entice the porting of Unix hosted software to mainframe. AFAIK it didn't gain traction.
Namely, C standard library was not reentrant safe, with considerable global variables et al - and the code on CICS (and I suspect TPF) had to be fully reentrant because it effectively ran inside green threads.
So, unless IBM wanted to advertise C that wouldn't contain standard standard library, modules written in C would be possibly dangerously playing with global side effects. Relatively recently this was solved by common runtime component whose name eludes me at this time, which underlies standard run times for C/C++ and I think Java, at least inside CICS