Not sure if this is academically defensible against the UML spec, but my understanding would go something like this:
The use case diagram intends to capture a functional requirement, reflecting some desireable outcome - production of some end that is of value to one or more of the actors. This is irrespective of the underlying implementation details. I think of this as being a description of "What?" should happen.
The activity diagram functions in my mind much like a flowchart, and intends to break the "What?" down to a high level definition of "How?". In other words, now that you know what it is being done in the use case description, the activity diagram helps express the business rules, logical constraints, timing dependencies and important algorithmic concepts of the realization of the use case. Some people even use swimlanes with activity diagrams to depict allocation of responsibility across system components, but I usually prefer sequence diagrams for this.
Speaking for myself, I don't usually find it's necessary to do a lot of activity diagrams, but when there is a particularly important business rule or other piece of functional logic that needs to be stated explicitly in the design, it strikes me as being useful. Usually a couple of these per model is my norm, but only for items which I don't think I can better express with other diagram types; even if there are many more use cases.
Remember too, that using the UML, you tend to have a certain amount of overlap between the various artifacts in your model. Along the timeline of creating your model and fully fleshing it out, you're basically describing the same things over and over, just at greater levels of detail on each pass. Sometimes with activity diagrams, there's so much overlap going from use cases to the other diagrams, I just continue on with the next level of detail instead.
