One big reason for the different tables was the following:
To represent registered users seperatly from non-users that need to be in the system.
An example: I wrote a meeting minutes module. In it the meeting has employees (i.e. registered users) but also may include the community. There needed to be a way to have those users in the system without, a) having someone register them or b) having the users register themselves.
This way at subsequent meetings that person is already in the system and doesn't need to have the minimal information put in. Also, I hooked this into a contacts application and now the data is in one location. Also, any other modules (tasks, etc) can have references to the non-registered person.
Another feature of this seperation is that if a user does register all that is needed is a write to the users table. Of course there was never an admin interface written for this and there were no triggers setup to look for a person before creating a new registered user, but the tables are there. This retains the information from before.
All of this came about due to some inflexibility in the 3.x code (and before). Before you start to consolidate all this remember, there was a reason for this abstraction. Of course, I still hate the fact that email is
the way that a person is identified, as one reason people may not be registered (at least in the public sector example above) is that they
don't have email. There are many cases where I hacked that out and used handle as the id. Many people don't like giving out there email and just type in bogus ones anyway (bill@microsoft.com).
Also, what happens when you want to record a company or group of people, hence parties.
