Writing and maintaining a huge document with highly detailed test cases is a huge pain. Often maintenance of the document gets in the way of actually testing the application!
On a related note, testing time is often what gets crunched. The question "Do you really need two weeks? We've got to ship in one week!" is very common. There is a strong need to open up and show management (and dev and other teams) exactly how much work there is to do. This is more true in testing than in dev, I've found, simply because coding is considered more of a black art than testing.
Sometimes you need to produce that impressive pile of paper to say "This! This is what's going to take us two weeks."
So, if you need to produce an impressive pile of paper and you don't want to spend a long time writing and maintaining test cases, what do you do? You produce paper that shows how you really test.
1. Test checklists. This is the poor man's test cases and it's a whole lot faster to write.
2. Bug verification lists. Just export this from your defect tracking system.
3. Automated test definitions. Whenever you're doing an automated test, you should be documenting what you're trying to test right there in the code. Run Javadoc, or Sandcastle, or perl2html, or whatever the appropriate doc generation tool is.
4. Test session plan. Are you doing exploratory testing? Put out your test mission schedule. This coordinates nicely with test checklists since test checklists match up to test missions.
And presto! You have a stack of paper that is impressively thick.
Don't fear documentation, just don't write it all by hand!