A few things here that have not already been mentioned.
First, is that a UNIQUE constraint can also be used for Referential Integrity. Per the BOL article on Unique Constraints and Check Constraints:
A UNIQUE constraint can be referenced by a FOREIGN KEY constraint.
This may be helpful with your database design depending on how complex you wish to get, but more importantly as Grant Fritchey explains, it can also help improve performance for certain types of queries if you do create a FOREIGN KEY constraint on it.
Secondly, and this is probably the more important fact, a UNIQUE constraint will likely be a smaller index to it's Non-UNIQUE equivalent, even if the Index Definitions are exactly the same. When a Nonclustered Index is defined as UNIQUE, the clustered key is implicitly stored as (an) INCLUDE column(s) (because nonclustered indexes have to point back to the clustered key). Alternatively, if the Nonclustered index is NOT defined as UNIQUE, the clustered key is implicitly appended to the Nonclustered Index Key and will exist at all levels of the index (making it bigger). Kalen Delaney does a much better job of explaining why this occurs in her posts on Nonclustered Index Keys and More About Nonclustered Index Keys.