TP 3.0 generated COM files (near code, near data, far heap-allocated data).
TP 4.0 generated EXE files (far code, near data, far heap-allocated data).
(the above is "to the best of my recollection": I no longer have the manuals for these toolchains; it might be the case that in TP 4+ all data is far (pointers to data were far)).
A TP coder was generally forced to live within these constraints (and adapt to the memory model changes described above across the 3 -> 4 transition).
Turbo C 1.0 came along within a year or so of TP 4.0, and (because it was actually not a 1.0 implementation but a rebranding + enhancement of an existing toolchain acquired by Borland) supported all permutations of x86 memory models, allowing the coder to choose according to their needs (and explicitly define near and far functions and data as needed independent of the memory model used w/o a need to drop into [inline] asm).
Turbo C's giving the programmer total control and optimization flexibility along these axes, which was a function of the language _implementations_, not the languages themselves, I believe contributed to the "C was faster" outcome (from TP 4 onward, there was (inline asm aside) IIRC no way to instantiate near functions). Turbo C was not the only C implementation for MS-DOS, but IIRC it immediately became the most popular, and held that crown for many years; other entrants needed to match Turbo C's features or die.
[edit]
Microsoft offered a MS-DOS C compiler (long?) prior to the release of TC 1.0, which supported the same memory-model permutations as TC 1.0. However it was at least 3x more expensive than TC 1.0, so when TC 1.0 was released at such a low price, it grabbed a lot of market share (by expanding the market to include programmers with smaller budgets). There were at least a few more MS-DOS C toolchain competitors already on the market when TC 1.0 was released (but I never used them so cannot comment futher on them).