Agree. I've built CRM's for multiple industries now, starting prior to any interaction with salesforce.
There are many reasons to keep leads out of contacts, messy imports and the unstructured nature of what a "lead" can be are big ones, traceability, unauthenticated data capture issues and ease in reporting are a few others.
It's always less of a kludge to have a system that keeps them separate but lets you seamlessly convert or associate a lead object into a contact object, when it makes sense (for lead objects that have sufficient similarity to a contact), and has an option to bypass the lead table and create a contact directly.
In my experience trying to shoe horn into a _contact only_ abstraction creates more problems because the abstraction is too simplistic or even flat incorrect for many businesses.
edit: From a sales agent "user" perspective you do often want to hide these abstractions from the UI depending on the industry and/or lead type, too many systems force their users into unnecessary duplication of effort.
There are many reasons to keep leads out of contacts, messy imports and the unstructured nature of what a "lead" can be are big ones, traceability, unauthenticated data capture issues and ease in reporting are a few others.
It's always less of a kludge to have a system that keeps them separate but lets you seamlessly convert or associate a lead object into a contact object, when it makes sense (for lead objects that have sufficient similarity to a contact), and has an option to bypass the lead table and create a contact directly.
In my experience trying to shoe horn into a _contact only_ abstraction creates more problems because the abstraction is too simplistic or even flat incorrect for many businesses.
edit: From a sales agent "user" perspective you do often want to hide these abstractions from the UI depending on the industry and/or lead type, too many systems force their users into unnecessary duplication of effort.