Although the names and technologies have changed, the problem of assigning blame isn't that different. In a conventional Web site, there are plenty of opportunities to mess up features, performance, and security. You have to create a complex hardware mix of Web servers, application servers, and database servers that can handle the load. You have to maintain and manage both the hardware, software, and network infrastructure. And, oh yeah, you have to write an application. With all that complexity, it's sometimes hard for even an expert to tell where the problems lie.
For example, I have seen people blame "slow hardware" when the real problem is that someone forgot to add a crucial index on a particular database table. Fortunately, SQL Server has tools that make it possible to identify the bottlenecks and determine the solutions. At the moment, mashups don't have those kind of tools. You may need to resort to similarly mashed-up debugging tools such as Wireshark, Fiddler, and Firebug to determine what's going on with the client. As for the cloud side of the equation, I've yet to see the tools that services like Azure will provide to let mashup architects find and fix performance problems.
There is also, of course, the question of reliability. Failures of services such as Amazon S3 have made many professionals skittish about using cloud services. However, I think that much of this is just the teething pains of a new industry. A decade ago, professional Web hosting services were dismal as well. I thought the turning point happened when the SQL Slammer worm hit; hosting companies realized it was in their interest to avoid chaos. We may need to see the same kind of disaster attack cloud services before they get their act together.
To sum it up, the details are different with mashups, but the system design issues are not so alien. There are no shortcuts for knowing what the heck your application is doing, no matter how you build it. There absolutely must be tools available so that you can peer into the cloud far enough to know where the performance bottlenecks lie.