I can't say I've personally found any advantages, I don't think I caught any bugs, but who knows... It's the right thing to do... Right?
Anyway, my team typically will claim they are too busy, and our end to end testing is good enough. And admittedly I don't think many of our bugs would be caught with TDD.
I'd like to think our software is critical, but we are judged on man hours saved rather than perfect first programs.
Any thoughts on if TDD is our only solution?
All this isn't to say don't use TDD, it sounds like perhaps it's not beneficial to your team. How confident are you in that decision? Perhaps you don't have many defects, but will your product roadmap lead you to complexity that will have them in the future, necessitating better processes later? Processes take time to mature, so maybe now is the time to prepare? Maybe you have very few defects now, but are they expensive or cheap to resolve? I would be considering these questions and looking at TDDs strengths and considering whether it's able to help me.
Additionally, you mention end-to-end testing. So are you validating work by manual tests rather than code tests? How much time are these manual tests taking? How much can you offload to unit tests? Will unit tests offer certainty that manual testing does not? One other thing I can say from experience is that manual testing doesn't scale. Will that be a problem for you?
If you haven't found any advantages after 4 months of doing it, why would you think it's the right thing to do? Lots of people call lots of things best practices, that doesn't mean they're a good idea or the right idea, but some of them may be.
It's a great idea to keep in the back of one's mind how they are going to test what they are working on. TDD is a very structured way of doing that so it could be beneficial but not an absolute necessity.
There’s no one “right” way to develop software. Either you have evidence or you don’t.