1) They're not really simple. If you take essential functions like a key-value store, that'd be a microservice. Simple ? Yeah right. Business logic ... simple ? Yeah right.
2) It's slower. You can wine all you want, but when it comes right down to it, there's a reason people avoid crossing the network, and the microservice approach essentially comes close to crossing the network every single time you cross module boundaries. You'll be spending 50%+ of your cpu time marshalling and unmarshalling and waiting for transmission, even on the same system.
This also manifests in all these "no-sql" datastores. They have all the problems of sql datastores, but they have one more. There's no way to have indexes. So in a table indexing all your sales by "id", the only way to find sales of product "X" is by going through each and every record (you can build indexes yourself, but it's not easy and it's sure as hell not flexible. Plus I guarantee you'll do it wrong the first 10 times). This means that retrieving 10 sales records takes the exact same amount of time as generating the yearly sales reports. In other words : you won't be doing it, because it takes too long.
3) There's just so damn many of them if you want to achieve anything useful. Every single one of them needs to be sufficiently well-designed to operate like an individual web server. So (d)dos-resistance, fairness, anti-slowloris, anti-starvation, autoscaling, resource exhaustion (like maximum number of file descriptors ...) correct sharding, access control (not too tight, not too loose, ... correct caching of security credentials, ...), and load testing, you've thought of all that for that "really small and dumb" service that basically copies information across the payment/non-payment firewall right ? If you haven't ... prepare to be surprised.
A related problem here is the shear amount of diagnostic monitoring you'll need.
4) They are inflexible, and don't deal well with different data types (this is one of the things object oriented programming solved). They work well when they deal with strings, or with company-standard datatypes. Only companies don't like to have company-wide standards. Yeah, I know Sun and to a lesser extent Facebook succeed at it, but does your company ? Last time I consulted at a bank they had systems interoperating using every interchange format from fixed-width fields (old cobol code), 5 different kinds of xml, and of course json and a dozen binary formats. Microservices can't work in such an environment. It destroys the flexibility of individual actors. The argument here, of course, is that that is a good thing, and I'd say you're right, but you've just created yourself a hell of a lot of enemies, some of them powerful.
5) It's extremely hard to orchestrate integration across multiple microservices. The first thing this will manifest in is testing. How do I test one service ? The answer is "unit tests" or "a system test". But this is the result of a fundamental misunderstanding. As a company, or even an IT department, you don't really care if unit tests and/or system tests succeed for a microservice. You care that if you connect a -> b -> c -> d -> e -> f -> g (and usually this is a network of microservices, not a sequence) that you can sell gizmos on your website.
Testing if that works requires throwing up three dozen services. Now first, having watched the netflix talks, they do this. Congrats. That's can't be easy. They also talk about the disadvantages : they have 3 teams doing nothing other that making that work, and it eats a significant part of their AWS resources. They can't do it on developer's workstations, nor even on a number of them.
The second thing this will manifest in is the cross-microservice redesign. Say a new law comes in. With a payment we now need to have a scan of the driver's licence of the buyer (say "gizmos" are treated like alcohol). So we simply need an extra image field going through the payment system. Oh-oh. The payment system is 8 microservices, and therefore around 64 interfaces to the rest of the system. Let's be generous ... only about 30 need to be redesigned. There is nothing to help. Refactoring, or even type checking doesn't work across microservice boundaries.
This presents 2 problems.
First is that it's a hell of a lot of work, even though most services only do basic things and don't care about the new data. But they still copy the data, save it, ... each of them needs logic to deal with missing data (historical data for instance), and the copy from one json dict to another needs to be implemented. And as you'll find every microservice has it's own methods for dealing with said datatype, you'll be checking up to 8 libraries for marshalling problems.
Second is testing. Any error you make won't come up unless you're testing multiple of those services simultaneously. If you manage to have just a bit more complexity in your system, those problems won't come out until the massive full-system integration test. You know, the one you can't do yourself, and even your whole department can't do. Oh-oh. That's an awfully long feedback loop to find those 3 dozen places where you forgot to copy that field across.