Duplication in code is generally considered bad, because it violates the DRY principle. Probably the only commonly accepted exception to the rule is documented in Extreme Programming Explained by Kent Beck. He says that the one higher priority (than removing duplicate code) in simple design is to ensure that the system "must communicate everything you want to communicate". In other words, the readers of the code need to be able to understand what it is doing by reading it.

Requirements in the form of Use Cases are no different in this sense. The Use Cases should ideally have no duplication within them, but it is actually more important that the readers of the requirements understand what is being described within them. In other words, if putting some duplication in helps your readers better understand what is going on, that's a good thing.

The main difference between these cases is the skill of the reader. The people reading the code are (probably) trained in how to design and write it. The people reading the Use Cases however are probably not trained. In many projects, Use Cases have to be signed off by representatives of the business with no training or experience in them at all. In such cases, being pragmatic about duplicating some sections of requirements may be perfectly appropriate.

Oh - and by the way, Use Cases are not design. If you end up with duplicate code as a result of having duplicated requirements, beat your developers with a stick. They should know better.