Z-Wave has a number of issues, some of which have been enumerated here to one degree or another.
1. Use of battery powered devices. This sounds nice, and for simplistic setups it's probably fine. But, in a real automation system, where the automation system needs to know the state of everything at all times, it becomes a problem. In order to save power, these types of devices often only wake up every couple hours or so. If you do any maintenance on the automation system, it could be a couple hours after starting it back up before it finally gets the status of all of the devices, which can be really annoying. It also means that these devices are send and pray, because the automation system cannot talk to them except for this very brief moment when they wake up. The automation system has no way to actively ping them to make sure it's staying in sync. You can often crank up the wakeup time, but if you set to anything very short you'll go through batteries fast.
'Beaming' is a relatively recent technology added to help with this. Devices wake up and go back to sleep rapidly, like a couple times a second, but very briefly so as to use minimal energy and just to listen. But, it means that outgoing messages have to be held on the network long enough to insure that the target device has woken up once during that interval in order to have seen it, and worst case it could be the full interval. This has to slow things down because another command can't be sent until the previous one completes. I don't know if they can cut short the interval if the response comes in (i.e. if they can correlate the response and know that they can drop the beam.) Even if so, the average time would be half of the interval, which would still be long compared to a non-beaming transmission. If not, then they would have to hold it 'in the air' for the full interval.
2. It's a semi-standard standard. There's too much leeway for the manufacturers as to how they use the various device classes. It's often the case that you can't support a particular module without having to explicitly code for it. There are way too many modules to get into that. We use a scheme where we have an XML file that describes a module, what classes it uses, what info it accepts and provides, what stuff is encrypted and what's not, etc... Even with a fairly convoluted set of such rules, it's still often difficult to support modules in this generic sort of way, and sometimes impossible because of vendors playing tricks or taking liberties.
Even when not taking liberties, it's still sort of a mess. I think there's something like 6 or more variations on how a lock can report it's lock status, for instance. Some are due to ongoing extensions of the device class interfaces (V2, V3, etc...) and sometimes it's because there's just multiple ways to do it and some vendors pick this and some vendors pick that. Some use generic device classes to send/receive some info and some use more device specific ones. Some depend on the interaction of two or more device classes in a way that you couldn't deal with generically and would almost have to support with custom code, which I just don't want to get into. Some use manufacturer propriety messages to do some things, which would certainly require it.
3. Without modules doing async reporting of status, it's pretty much a lost cause to try to have real two way control. The Z-Wave network isn't remotely fast enough to poll any significant number of modules at a rate that would keep latency to a useful minimum. If you open a window and it's not seen by the automation system until two minutes later, that's semi-useless. More and more devices are supporting this, BUT it means that a significant chunk of the actual configuration of the automation system isn't in the automation system, it's spread out all over the place in each module, because it requires setting up the async reporting (the interval, where to send them, and often what is set) in the modules themselves in many cases. You can of course record this in the automation system, but it's not practical to constantly re-push this information out to the modules. And the speed of the Z-Wave network would mean that fully pushing out all of this info every time the automation system (or driver) starts up could mean no control available for some time until it's all done. And it could somehow change any point after that without the automation system knowing it.
4. As mentioned by someone above, real control over the modules requires knowing detailed information about what device classes they implement and what versions of them and so forth. This is often a state secret of some sort that can be almost impossible to find.
5. Unlike technologies like Radio RA2, in which the automation system is completely insulated from the details of the underlying networking system, with Z-Wave you have to do with SO many details, it's stupid. Even using something like the VRCOP only helps somewhat since it's still a relatively like wrapper around a Z-Wave node. It requires an effort that's far out of balance with the benefits of supporting it for the most part. Yes, you can heavily concentrate on Z-Wave and get the best out of it it can provide, as some companies have. But there are a lot of other technologies out there as well that need to be supported as well, and time doesn't grow on trees. So, when one takes undue time and effort, it's probably not going to be integrated as well as those that take integration seriously and make it straightforward for the automation system manufacturer to deal with (and, importantly, which protect the system from the automation system as well, which is not the case at all in Z-Wave where the automation system is directly a node on the Z-Wave network.)
6. Reliability. This isn't a Z-Wave specific thing, it applies to all of the consumer level lighting systems. Some people do well with them, some do OK, and some end up giving up before they have a stress related heart attack. These systems aren't overbuilt like pro level systems are, so it's like they have 'just enough' to handle reasonably optimal circumstances then fall down to one degree or another, whereas higher end systems aren't on the edge like that.
Often the discussions on this front are apples and oranges comparisons, where one person is using the technology in a very simple way, mostly to just send outgoing commands to modules. In this case, the controller just sends out every command a few times, and it's likely they will arrive and it never over-stresses the Z-Wave system. Another person may be using it in a serious automation environment, in which robust two way control with minimal latency is a requirement, and so have a very different experience, because Z-Wave really wasn't ever designed to support that sort of thing.
Also some of our customers have reported limited success if they start mixing modules from different manufacturers, only being able to maintain a stable system if they stick strictly to Leviton devices.
7. You have to be pretty strict about how you physically handle modules, and some folks just aren't gong to be. Z-Wave isn't, as I understand it, and ongoing, self-healing mesh network (which maybe Zigbee is more of?) It finds neighboring (non-battery) nodes during network setup and uses them to pass along messages. You can't just yank out a module and move it without causing issues, and probably it happens often enough. Or, you change things around in the room and suddenly a previously good neighbor becomes a flaky neighbor due to interference and whatnot. Maybe this has gotten better in recent years, and maybe it's more self-healing, someone correct me if I'm wrong here. Any technology to target non-technical users probably needs to assume the absolute worst case and always be prepared to re-jigger itself for maximum performance on an ongoing basis.
Anyway, that's my view of it. I don't mean to sound overly critical. All systems to one degree or another have their issues. It's a complex real world out there and any time you try to deal with it from a piece of hardware or software it can get really wierd. But these are the concerns I see wrt to Z-Wave, and some of them are due to the design of Z-Wave itself and the lack of strict standards for module manufacturers, not due to the world being a dangerous place.