I follow relational principles and only use surrogate keys when the natural keys are compound and large.
For example, many organisations assign a "personnel number." to each employee, so using "Person(.nr) fits this paradigm. (i.e. it is a natural key whereas the autonumber ".id" isn't)
Although, philosophically, you could argue that the "personnel number" is a surrogate key -- it's just an externally allocated surrogate key. But it serves the same purpose and was probably introduced for the same reason by the "original" modelers. ;)
I think you're right though that a lot of OO approaches use surrogate keys as a simplifying assumption and maybe aren't as rigorous in their modeling. For this case, however, with a table like User/Person, I think the main reason is the stability of the key. In a web service environment, for example, what would be a good natural key? It's common to require unique e-mail addresses, but those change fairly often. It's common to have a unique username or screen name, but those need to be changed occasionally too. I realize with cascading FKs that's simple to enforce, and maybe I'm too embroiled in implementation details, but in my experience, the User table is by far the most commonly referenced entity. So it seems all-around simpler to have an artificial key for that purpose. Not that that should eliminate the natural constraints, of course.
As an aside, and I know I'm new here and probably naive, but I've been reading the forums and had a few reactions:
There are discussions about how to raise awareness of ORM and to get more widespread adoption. And certainly I think stuff like NORMA and CQL are key to that (I'm kind of blown away by how amazing they are, actually).
But also, I see the "Contributed Models" forum and there's almost nothing there. I know there's the Talent Agency, IT management, Bird classification models, etc. in the library, but those seem largely geared toward pedagogical use.
What I would like to see is smaller sub-schemas that can be reused in projects (and I know from reading some of Clifford's stuff that his work on CQL attacks that problem to some degree).
I'm just saying, look at it from my newbie perspective: I certainly want to become a better modeler. But I also have a job to do. In the same way we use design patterns in software development, it seems to make sense to use information patterns for modeling. If I could pick up an ORM model -- with the imprimatur of world-class analysts -- and adopt it into my own project, why wouldn't I? Maybe more importantly, why wouldn't my boss require me to?
In the ruby-on-rails world, for example, there's a bunch of plugins for common use-cases. A plugin for users, roles, attachments, blogs, etc. Each framework builds on the other, reuses certain design ideas, etc. Wouldn't it be cool to have them all using the same fundamental information model regardless of framework or database technology?
It just strikes me that perhaps focusing on ground-up influence of ORM may be as- or more effective than top-down approaches -- similar to how the strength of ORM lies with starting from the facts. Clearly there's enough commonality of use-cases, at least for web services, that the ruby-on-rails community rallies around certain plugins. It doesn't seem any more far-fetched to me that everyone can rally around a given sub-schema model, which is then implemented in a dozen different frameworks, all referencing the ORM model as proof that it was done right (tm).