A primary key is really just the combination of the unique and not-null constraints. My preferred way of handling this is to have a surrogate key as the primary key (for performance and general ease-of-use), but also apply multi-column unique constraints on the natural key to enforce data integrity. The main place where I don't use a surrogate key is for many-to-many join tables (which I think is the common practice).

I think your point is valid, but I'm not seeing the instance where a duplicate rows couldn't easily be identified as being exactly that.

I suppose in a fully normalized world of enterprise db architecture this could be an issue, but most real world applications aren't built that way.

In reality, speed is key, models are simple and normalized data is usually the bottleneck, and as such, de-normalized PDQ.

I know the theory is whack and risks problems, but reality pays the bills in most cases, so it wins.