You raised a few point, I will try to address them all:
1) JUnit is only good for the "gear" and not for the "engine"- Confounding JUnit to the "gear" is somewhat limiting and does not do justice to JUnit, with a little out-of-the-box thinking and the use of advance JUnit features like parallel testing one can create test suites that test functionality and integration as well as units.
2) call/callback are two methods - I am not sure my point was understood, let's say I want to invoke an asynchronous method (like opening a non blocking socket in NIO), I can not tell if the expected result had accrued without a callback mechanism. I hope this example make it clearer.
3) JUnit is white-box/black-box - well, if you take a unit and you invoke method in it, the unit itself is a small black box, you are not aware of the internals of the process. JUnit tests functionality in a Boolean manner, if the functionality is correct but the process is faulty JUnit will not be able to detect that. I did not understand you comment about "finding memory-leaks with JUnit will be difficult, since your tests don't run in their native environment (the application), but in the test harness", can't a unit leak memory?
4) "How is it difficult to write unit tests in Java" - nothing is difficult if you know what you are doing, we could all write our tests in binary code. My point was that some people think that writing tests using scripts is easier and nicer.
5) "Toto, I don't think we're in Kansas anymore" -I find the title of your comment somewhat unclear, I hope you meant "I really enjoyed this article..." :)