There are two distinct approaches that the industry has taken towards platform as a service (PaaS).  The first approach is offering an integrated and vastly simplified programming model in the cloud.  This provides all the infrastructural benefits of Cloud Computing like multi-tenancy, automatic upgrades & elastic infrastructure PLUS it speeds up application development considerably.  Force.com is representative of this approach. I would also encourage you to checkout Mike Kreaden and Peter Coffee's blogs.  Mike relates Force.com to 4GL environment and Peter refers to three independent studies which quantify the productivity improvements of developing on Force.com – one study found a five fold improvement in developer productivity.

The other approach is to wrap existing products and APIs into a PaaS.  Essentially, the approach involves packaging existing products (database, middleware, tools) into a deploy-able unit and them provisioning it for each tenant into an infrastructure cloud – either something like Amazon or a custom built one.  This may be somewhat of an over simplification but the fact remains that these existing products were not built for a multi-tenant environment so some form of retro-fitting or working around is required.  Even if we assume that the provisioning and management infrastructure works smoothly to provide the infrastructural benefits of cloud computing, you still have to deal with the same old, complex application development model.  The JEE for example, has over a dozen APIs that you need to learn and then each of the each component – the database, the middleware etc. has its own tools and tricks.  So this approach does nothing to make it easier and faster to build applications.  Most incumbent middleware vendors (and you know who they are ) follow this approach.  There are a variety of marketing spins given to this approach – choice, legacy portability and ironically developer productivity.  However, the main reason is to protect their existing franchises – however, as the saying goes a hog in armour or in this case development complexity remains complex.