I still lost count of the times a unique constraint that needed to be removed made for much more of a headache than if it hadn't been there from the beginning - because it turned out to never have been neccessary, but you still had to care for the uniqueness assumption in all associated code.
Where you work do people never make uniqueness assumptions in application code unless there's an explicit unique constraint in the database? That's impressive. Are you hiring?
It's just an observation based on experience (two decades in different companies of all sizes btw.) about the most blatant cases of this kind: the constraint was just set based on that rule of thumb, and since it was there in the schema, it was taken as gospel and any code throughout all the layers written with it in mind and shortcuts taken accordingly, all while there never was any requirement for it nor was the uniqueness actually assured (cf. those posts about names) and the breaking only a matter of time.
Mabye I've become jaded, but I've come to see those as being among the most annoying and unnecessarily time-consuming classes of issues.
Where you work do people never make uniqueness assumptions in application code unless there's an explicit unique constraint in the database? That's impressive. Are you hiring?