In the context of software engineering approaches, "What research exists?" is basically a conversation killer of a question. The scientific method, when applied to medium-number, complex-interaction systems like most business settings, offers very little in the way of predictive power. At best, it may illuminate some dynamics and raise some questions to ask, but rarely predict the future in the way that hard sciences research does. This is why, if you a predisposed to label something like TDD as "cargo cult", you will likely never find any published research to be "convincing".
But that said, a simple search for "published tdd research" turns up quite a few hits, including this one from Microsoft right at the top: http://research.microsoft.com/en-us/groups/ese/nagappan_tdd....
However the benefits of testing can seem rather obvious if you are in the software industry. We hire people to do QA, and if the developers write tests, we can hire fewer people to do QA and still meet reliability targets. Software development is a loop: design -> code -> test, over and over again, and automated testing means that the code is still fresh in your mind when you fix it.
But it sounds like you're wondering, "why test at all?" Well, would you sell a car or a table saw that had never been tested to a customer?
It's absolutely not worth it. By the way, I have a codebase with 240k line of early 2000's guaranteed-untested PHP, coded by the best and brightest and complete with best-of-breed programming practices such as global variables I could maybe interest you in. I also have a full complement of bridges available.
> I never read about any actual convincing research that shows TDD as actually being beneficial.
TDD? That's probably good when you know what you are doing, but I must admit I'm a "test after the fact" man most of the time. Probably because I don't know what I'm doing most of the time :)