A list of use cases can give you a fairly good idea about what the system needs to do, and it usually fairly easy to quickly come up with a set that's representative of what's actually wanted by the stakeholders. Finding use cases should involve stakeholder and user team members, and incorporating these people into the process has the advantage that they will become better disposed towards the project (provided they are treated with a modicum of respect).
Use cases are informal enough to allow good communication with the stakeholders, giving them the feeling that they understand what the system will actually do. This increases their confidence in the project. Use cases are also quite specific in detailing what the system has to do, thus reducing misunderstanding and ambiguity that is often associated with informal requirements.
The list of use cases also gives a good idea of size of the system overall. Because each use case should have the same granularity, describing roughly the same ``amount'' of interaction with the system, a collection of use cases will give a better idea of the complexity of a system than a list of randomly-sized requirements. They can also be used to derive test cases, to estimate effort (by tracking the number of use cases completed versus time spent in any stage), and to guide documentation.
However: identifying candidate use cases for actors does take time and effort away from more obviously ``productive'' development or from users' and stakeholders' revenue-earning work. Listing use cases can seem pointless to stakeholders who already ``know what the system should do!'' especially if they already have other kinds of lists of requirements for the system, and if it turns out that those lists are wrong.