I've consulted on SQL Server for over 2 decades for scores of clients ranging from Mom-and-Pops to Fortune 100 and guess what, they ALL produce crappy designs and crappy code (language edited for younger readers). It doesn't matter whether they do logical modeling first, just physical modeling, let the code write the data structures or just some whiteboard sessions - if that. Some of the most egregious stuff I have seen actually comes from the big boys with teams of staff to cover all phases of the application life cycle.
In my experience, what really happens is that they do not do a proper logical model. And that inevitably yields crappy designs. Instead, they just slap a physical table together -- "design" is typically a vast overstatement. [And almost inevitably every table starts with the unkillable myth of the "identity as clustering key on 'every' table". While at times a unique identifying number can exist in a logical design (at least for me, Celko may differ on that), although only when absolutely necessary, such as a customer number, an "identity" per se of course cannot.]
One good hint: If you don't/can't have business people in the initial design meeting because they won't understand it, then you're not starting with a logical-only design.
Heh.... I always end up with the myth that a clustered index always has to be based on some natural key. As a result, we have to go through absolute hell to find everywhere that the natural key of Client and LoanNumber have been used in a couple of hundred places because of a merger and either or both the Client or the LoanNumber has changed.
Also, and this is where the physical design comes in to play, a clustered index on an identity column isn't always present for the sake of being present although I'll almost always have such a thing. I use it to control frequent multi-row inserts while still keeping the rest of the table accessible.
Since this is physical design rather than logical design, I'm not sure why you brought that up in this particular conversation. 😉