Leads have specific uses: queues, lead assignment rules, auto response rules, web-to-lead, "unread by owner" field, campaign integration, and reporting.
Let's go over each feature in more detail, shall we?
Queues
Queues let groups of people pick from a common pool of leads they want to follow up on. Very few organizations use this feature as it is, I believe, instead deciding to use assignment rules for specific types of leads.
Assignment Rules
Great if you want to get the right leads to the right people, either by territory, product interests, or whatever else you might consider. This is probably one of the most attractive features of leads (besides web to lead and campaign management), although you can emulate this with territory management or workflow rules.
Auto-Response Rules
Great way to let your leads know that you've accepted their request. People like to know that. Workflow rules can emulate this on contacts/person accounts.
Web To Lead
Love it or hate it, it's an easy way to put up a form for accepting leads. I'd say that more "mature" organizations have already moved past this very limited feature anyways, but if you're not there yet, you might hold off.
"Unread By Owner"
This feature lets you run reports on who hasn't followed up on leads. There is nothing like it anywhere else in the system, and it's pretty useful to have. It is technically feasible to build this for contacts, though, with some Apex Code, Visualforce, and Workflow rules and/or scheduled Apex Code.
Campaign Integration
Campaign integration is, among other things, a pretty awesome feature. Unlike contacts, you can import new leads and associate them to the campaign at the same time. When you convert the leads to opportunities, you automatically get ROI reports with no extra effort. You can mass email those leads by campaign. You can make list views by campaign to see which leads are where. Conversion percentages give you the effectiveness of your campaign efforts. In short, campaigns and leads work well together, and you'd be amiss to throw this away without a second thought.
Reporting
ROI reports. Conversion reports. Market segment reports. Email Campaign reports. Reports. I'm not saying that you can't get at this data without leads, I'm just saying that you're discarding a bunch of out of the box functionality if you do. Now you've got to remember to associate the contact to the campaign. And the opportunity has to be associated, separately. Plus, you don't know how long they were waiting from the time you learned about them until they were converted to opportunities. All of these juicy details are there for the taking.
No Leads?
I understand that many organizations hate the leads feature. I worked with technical support for four years, and I've worked as a consultant for five. Here's the problem with leads: they require, at minimum, more effort to get started, more effort to get configured, and quite a bit of effort to realize the full benefit of leads. This leads to questions like the one presented here: "How can we get rid of leads?", "How can we avoid duplicates?", "What is even the purpose of leads?". The question here shows that you're already at the tipping point; users aren't converting leads, aren't taking the time to "de-duplicate" leads, and aren't using them properly. Leads, in short, are the least understood feature of the entire system, and until you grasp their true value, you can't appreciate them.
Let's take a look at each "benefit" you mentioned.
No more conversion of records
... and no more awesome reports about how your conversions are driving sales, your ROI for campaigns, and everything else.
No more dupe checking across two objects
A lead and a contact in the same organization are not duplicates. A lead is a potential you want to follow up on. Here's the deal: You call the lead, you ask them if they're interested, and you convert them if they show any interest. The system does a pretty good job of de-duplicating leads into existing contacts automatically, except for those fringe cases like "Rob" versus "Robby" and "Bill" instead of "William." But, odds are, you might still end up with duplicates. They're not that hard to merge. Honest.
Master-Slave object relationship possible for objects that were previously required to be accessible from both the Lead AND the Account (Rollups, etc)
Right. The problem is, while leads provide great amounts of information, they are transient. If your leads are older than a week, you're doing something wrong. Nobody in their right mind is saying that you should have a custom object with a "lead qualification questionnaire" that must then be converted to the contact. That's absolutely insane. Additional triggers, additional lookups, and so on. But if you have to ask/state this question/benefit, you are trying to abuse leads, and that's why you want to get rid of them, because you don't understand the feature.
Once initial reprogramming of PHP and Apex is done, much less ongoing programming (only one Object to deal with)
Person Accounts are still two records, and you still have to be cognizant of them as quasi-independent objects. Instead, let your PHP deal strictly with leads if it is lead-oriented, or contacts/accounts if it is account/contact oriented. It is incredibly rare that you would have a solution that absolutely requires you deal with leads, contacts, and accounts in a single PHP script. If you're de-duplicating across lead/contacts, you're doing it wrong.
Conclusion
Nobody's making you use leads, and it's your CRM to do with as you please. However, simply saying that you refuse to use leads because they are worthless instead of trying to work in harmony with them is like preferring a lawyer over marriage counseling. I completely agree that using leads is something that has to grow on you. It's an effort. But I believe you'll be pleased with the results if you give it an honest try.
Best Answer
This is essentially the same problem as discussed in this thread. If you have already migrated to Customer Communities, this issue is already fixed by Salesforce so you should not get the above error. If not, you have a couple of options
A) Create a wrapper class of the fields you need, query the contact by id, and let the customer edit. Then take the wrapper and write back to the contact (certified to be working by the submitter for original thread)
B) Get a different license type like Service Cloud portal, Customer Community for read access to contact and Partner Community for full CRUD on Contacts (in addition to the full sharing model).