So, they ask, why should developers work against the test-cases created by testers?
Great question. TDD doesn't suggest that the test cases be written by testers. The fact that you're folks are suggesting it indicates that all y'all aren't comfortable with TDD and are inserting extra steps in the process.
Their question points up something important about TDD.
Testers don't write all the tests. Indeed, they shouldn't write many of the tests. Some folks say they shouldn't write any tests.
[Tests] are for verification and are based on the higher-level specs created by the UX team, which ... is sufficient for developers
Yes, but.
Those "higher-level specs created by the UX team" aren't always the best description of a system. That claim -- "[Tests] ... are based on the higher-level specs created by the UX" -- is suspicious and often wrong.
What is the actual benefit of BDD/TDD, if you already have a test-team who's test cases are fully compatible with the higher-level specs currently given to the developers?
That involves a false assumption, again. Specifically "test cases are fully compatible with the higher-level specs currently given to the developers".
Concept -> JAD -> Specifications -> Tests -> Code
is what you have in place now. Multiple, linear transformation steps. Each step introduces some error.
Concept -> Expected Test Results -> Code
Has fewer transformation steps and fewer errors introduced along the way. The users (or the users with some help from facilitators) can write the test results directly.
I did this for the first time a few years back and it was wildly successful. At first they wanted design documents -- which we all wrote and passed around. But I demanded specific test case results. I created sample test results in spreadsheets. It took a while (weeks actually) but the users eventually corrected my mistakes and sent me hugely expanded spreadsheets. They added necessary clarifications in the form of test cases.
They also wrote notes and comments. A bad habit.
I wrote a little utility to transform the spreadsheets directly into unittest code.
At the end of the first attempted release, the users had numerous complaints and corrections and bugs to fix. There was lots of IT trouble-ticket and status reporting going on. Change control. All that stuff. All largely useless.
We walked through the spreadsheet with the test cases. They fixed the errors in their spreadsheets (there were one or two). They kept trying to explain their notes and comments. I kept asking for examples instead of explanations. Eventually, they started revising and expanded the spreadsheets to cover the bugs and features completely.
Eventually every note and explanatory comment was backed up with a concrete example.
At this point, we -- the users and I -- were doing full TDD. Spreadsheet test cases to unittest code to production code. IT managers were fumbling around with change control documents and specification updates. All that documentation simply described the spreadsheets which had the test cases.
Once that first release was in production, the "Phase 2" requirements were entirely provided as test data on spreadsheets. 100% example-driven. No comments, no notes, no explanations to speak of. IT got out of our way and stopped trying to write English specifications.
Concept -> Expected Results -> Code
That's one benefit of TDD. You didn't ask about refactoring, so I save that long, boring war story for someone else's question.