Number of people using is an irrelevant metric. What matters is when (what conditions) you should use it.
If you design your implementation before writing your code (which most any skilled engineer can and should do), TDD is just codification of the design. If you skip that step, then you can't do TDD.
If the number of bugs is irrelevant to the release of the product and it's adoption (ex: internal application with a captive user base), TDD adds cost that may not be worth it.
If you have no/fluctuating requirements and the timeline won't allow for it, it's unlikely you can do TDD (lazy enterprise approach).
That said, even if your team isn't bought into it, that doesn't preclude you from adopting it as a rigorous process that results in you delivering a better product with lower failure rates.
I like trying out approaches just for the sake of it, at the least i will try it out in the future. Will definitely share my experience too. Thanks @asparallel
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.