Visualforce is a wonderful thing. User interface requests that used to be impossible or at the least very complex to implement in Salesforce are now quite do-able. The end users at my organization look at my latest Visualforce creations with eyes wide and mouths agape, dreaming of the new world of possibilities open to them. But with great power comes great responsibility, and I feel it my duty to caution people of the disadvantages of Visualforce.
There are two major down-sides to replacing standard Salesforce page layouts with Visualforce pages to be aware of going in. These don't apply to VF pages created to supplement the standard SF pages, which have no down-side that I can think of and I'll soon post about some rather nifty pages my developer-in-training and I have come up with. The first is the loss of on-demand configuration. The days of calling your SF admin, requesting a new field and having it magically appear 5 minutes later are over once you become dependent on VF for creating/editing records. Gone also are the days of non-technical power users being able to go in and quickly add or change fields. Adding new and changing existing fields, as in olden times (e.g. 10 years ago), will require a developer to make the changes in the Visualforce page, possibly in a related controller/extension as well, in the development environment, test the changes and then deploy those changes to production. If any development is already ongoing in that page, you may find yourself having to wait for that development to be completed before the developer is willing to make and deploy the change you want. Companies with larger Salesforce implementations are no doubt employing development best practices and scheduling releases of new code into production. This also applies to changes in the VF page layout; there is no dragging and dropping of elements on a VF page around as you please (not yet, anyway!).
The second down-side is that end users will become detached from the design of Salesforce objects, which is going to make report creation more difficult. As much as my users have complained that they've been forced to enter data for 3 different objects into 3 separate forms, it has at least forced them to gain a certain understanding of how all of those objects are related. That understanding is invaluable when creating SF reports. Users that are presented with a single, wondrous VF page that allows them to create and edit records across two or more objects may not even realize which objects they're interacting with, and therefore won't know where to start to create a report on that information.
The point is, Visualforce pages will make users more dependent on developers. Often, the benefits of a slick VF page far outweigh that cost, just be sure to understand that it is a cost when deciding whether or not to implement a new VF page.
