Unit tests are never perfect at capturing functionality, particularly in certain parts of an application (such as the GUI), so everyone needs some measure of black box testing. Does TDD have anything to say regarding black box testing? If it does not say much, could it be true that while writing unit tests is the developers job, functional black box tests fall into a different domain like that of a business analyst or a dedicated tester?
TDD has evolved to include black box testing, BDD quite specifically uses it as a device (see ATDD).
However, I don't think this answer tells you in whose domain black box testing lies. Personally, I think it lies with everyone. The BA knows what the business wants and Developers and Testers understand edge cases that a BA should never need to understand, often both with completely different perspectives.
And this is why the Gherkin-based test runners have become popular, because they allow BAs, Devs and Testers to write the test cases in the same language as each other (though developers have to put some code behind the text).
Does TDD have anything to say regarding black box testing?
You must write the tests first. Therefore, there is no "white box" because the code does not yet exist.
The distinction between black box and white box means essentially nothing in the TDD context.
...could it be true that while writing unit tests is the developers job, functional black box tests fall into a different domain like that of a business analyst or a dedicated tester?
Yes. Of course.
TDD does not mean "rigidly follow some brain-dead path."
If you want to do additional testing of the GUI, that would be a well-accepted idea.
IMHO TDD is primarily a whitebox technique, and, I think it is more an implementation technique than a testing technique. When a developer creates code in very small iterations "write test, write code, refactor", it is usually the same person who switches between code and test code, someone who knows exactly the already implemented parts, the missing parts of the "subject under test" as well as the test which are missing.
When you work that way, notice you sometimes have to create a new function, maybe with some minimalistic implementation. But then you change, extend, refactor and test this function, until it meets your idea of a featureset. So most of the time you work with existing code you know - on both sides (production code and test code) in parallel.
That means, when a developer who applies TDD creates a test for a function, they take the knowledge into account about the already existing implementation. They know which missing feature or edge case is still untested, or which code paths are already covered by the existing tests. That will undoubtly have a big influence which tests they create and even more, which not, since they know it is not necessary.
In fact, there is also a black box element in TDD: whenever you create a new public function to be tested, you have to think about the function signature or the API from the view point of a user of that function or API first. And whenever you add a new test for a functionality your "subject under test" does not support yet, you can do this without having decided about how to implement the functionality in detail. But IMHO that black box part is very different from a real "black box test", where an external tester who may not even be a developer does not have any knowledge about the implementation of a program.
Much like the "field of testing" development, one kind of testing never really excludes another kind of testing.
As long as you follow the testing approach, you can test your software in multiple ways. That might mean not doing black box testing while you're doing TDD, because TDD would require violating the black box rules on internal inspection; however, a second team, or even the same team revisiting code they no longer fully remember could do black box testing in a subsequent effort.