Now to the protocol question. 
My college major was Computer Information Systems and I went on to work for IBM until the wheelchair-thing. My first commercial install was in a nuclear power plant. So I’m very interested in network protocols, and had worked with all of the ones you mentioned before ever starting with home automation.
As with many things, the choice for any individual device comes down to how you specifically want to use it.
ZIGBEE/ZWAVE: MESH KEEPS COSTS DOWN
Zigbee and Zwave were both designed for “mesh” networks where there would be a lot of mostly dumb, mostly cheap, often battery powered devices where any given device might be occasionally unavailable, if only to have its batteries changed.
In a mesh network, the hub doesn’t panic if a device is unavailable. Every device is allowed to choose from several alternate pathways. Messages can passed around the network, neighbor to neighbor, until they reach their destination. If a neighbor is unavailable, you try again with another. Many messages get resent a couple of times.
This design keeps the network “resilient” (one node going down is no big deal). It keeps energy use low, which means batteries last longer. It keeps device costs way down.
WHAT MESH DOESN’T DO WELL
But there are two things it doesn’t do well. First, there’s no way to guarantee the exact sequencing of action requests because they tend to bounce around the network for awhile. You can turn on several lights at about the same time, but you can’t guarantee which will arrive first. In a roomful of lights this can lead to a “popcorn” effect when changing state. For the same reason it’s pretty bad at video or audio streaming because it’s possible for packets to arrive out of order.
Second, it’s really intended for deployment where it’s ok if you only force check device status no more than once every 15 minutes or so for plugged in devices, and once a day for battery powered ones. The devices will still tell the hub when they know something happens, like an open/close sensor detecting a window opened. That’s no problem. But the hub shouldn’t be sending, “hey, buddy, you awake?” Messages (polling) to devices on a mesh network very often, or you increase power draw and network traffic considerably. Nothing kills a mesh network faster than excessive polling.
This is all true whether you’re using SmartThings or any other brand of zigbee/zwave controller. For example Philips Hue does not let their Hue Bridge force poll all the bulbs (which are zigbee) at once. It does a few at a time in the background. Their assumption is that whether you’re turning lights on or off, it’s ok if it takes the bridge a few minutes to update the bulb status because the human can see if they’re on or off. It’s more important for the rest of the bulbs to still work even if you happen to be changing one. So mesh.
But you don’t choose mesh if you absolutely must have things happen in an exact sequence, or if you must know the exact status of the device at all times.
Mesh networks are intended to carry small packets for short distances at a low cost in energy and dollars, and to be able to deliver messages even when some individual devices are temporarily unavailable. That fits a lot of residential home automation use cases.
ZWAVE vs ZIGBEE
Zwave and Zigbee are pretty similar for most purposes. There are a few specific reasons you might choose one over the other for a given device.
A) zigbee is the same all over the world, although different regions may set different restrictions on the amount of broadcast power an individual device can produce. Zwave works at different frequencies in different countries. As of October 2015, the ST hub is sold in two models,one for the US/Canada/Mexico frequency and one for the EU frequency.
B) zigbee works somewhat better through rain than Zwave due to its use of DSSS. Almost all outdoor sensors will be zigbee. That includes utility company-provided smart meters. So you do also see zigbee on some indoor devices that are intended to communicate directly with outdoor devices, like energy monitors and some thermostats.
C) cordless phones and WiFi can interfere with zigbee. Baby monitors and intercoms can interfere with Zwave. The WiFi thing is why most devices other than sensors and lightbulbs sold for indoor home automation use are zwave. (You can reduce the likelihood of zigbee and Wifi causing interference for each other, but it requires smarter, and consequently more expensive, equipment.)
D) zwave devices are less likely to use manufacturer-proprietary encoding than zigbee, which means zwave devices from different brands are more likely to work together well.
E) the exception to D) above is lightbulbs. The Zigbee Light Link standard (ZLL) was intentionally designed for interoperability among different brands. (It helps that even the smartest smart bulb is pretty stupid and only does a few things: dim, change color, change color temperature.) For some highly technical reasons, and because zigbee antennas are smaller than zwave antennas, zigbee is usually the best choice for light bulbs.
F) zigbee usually gives a little better battery life, so is often chosen for physically small devices like little sensors.
G) zwave is limited to about 230 devices per networks while zigbee can handle tens of thousands. And zwave allows a maximum of 4 hops for one message, while zigbee home automation allows up to 30 (15 in to the hub and 15 out again.). For large sensor nets such as may be used in hospitals or hotels or commercial buildings, zigbee is typically used.
H) zigbee antennas are smaller than zwave antennas. So very small devices are usually zigbee. However, the newest generation of zwave, zwave plus, is somewhat smaller than previous zwave generations.
So in a residential installation usually tiny sensors, light bulbs, and outdoor devices are often Zigbee, and everything else indoors that’s mesh is Zwave. But if there are features on a particular device that appeal to you, you’re usually fine going either way.
WIFI: STAR NETWORK
WiFi is typically deployed in a “star” network, meaning every device talks directly to the central hub.
That’s great for keeping track of the status of every device.
It’s excellent for forcing packet sequence.
But it also means every device uses a lot more power than in a mesh network. The original Lockitron, for example, had to be withdrawn from the market because it turned out the reason no one else was doing a WiFi doorlock was that battery life was terrible. No surprise. (Their second generation took the WiFi transmitter out of the doorlock and used Bluetooth instead.)
WiFi in residential installations also tends to go on and off fairly often.
And a star network requires that each individual device have an IP address, limiting the total number of devices in the home.
And all the WiFi devices are competing with each other for the same bandwidth, so your Xbox and your garage door opener might be interrupting each other.
The reason Belkin’s WeMo didn’t just own the home automation market is because of all of the above. Read the Amazon reviews of WeMo and you’ll see complaints about switches going offline every few weeks and then having to be reinstalled each time. That’s a lack of resiliency.
You can make a star or tree network very robust, but it requires spending more money and rigidly controlling scheduling, something that doesn’t fit most home automation scenarios.
On the other hand, wifi is perfect for audio or video streaming. It’s also good for forced sequencing.
WiFi-enabled
Some more expensive devices may use zigbee or zwave as their main communication protocol, but are also “wifi enabled” so they can send some notifications via the Internet or maybe work with IFTTT. Sometimes that gives you some of the benefits of both protocols, sometimes it’s the worst of both. You just have to look at the details.
OTHER OPTIONS
not to go into too much detail, but point to point, as in regular bluetooth or RFID tags, is low energy, and allows forced sequencing. The negative is very short range, reliably around 30 feet. Apple’s HomeKit will use Bluetooth, but not a lot of device details yet.
Thread is the protocol used by Nest. Like zwave, it can only handle about 250 devices per network. The Zigbee alliance and the Thread group have a cooperative agreement which recognizes the strengths of both.
Bluetooth mesh was just approved a few months ago as a standard. It will have the usual advantages and disadvantages of mesh.
The ST version2 hub has a Bluetooth antenna, but It’s not turned on yet.
SUMMARY
For indoor use where you’re OK with things happening at about the same time but not necessarily in a specific order, right now certified zwave is probably the simplest choice. It won’t run into wifi interference, it has a high degree of interoperability among different brands, good battery life. Just don’t add extra polling.
For outdoor use, tiny sensors where battery life is critical, things that have to talk to an outdoor smart meter, and light bulbs, consider zigbee.
For devices that stream audio or video, or where you have to force sequencing, or where you want more frequent status updates, consider wifi.
For devices that need near perfect constant status monitoring, use cellular. Or hardwire for local monitors. But neither of those work with ST. (These would typically be medical monitoring or expensive commercial alarm systems.)
ONE CONTROL CENTER OR SEVERAL?
At my house my SmartThings installation uses zigbee smart bulbs and a couple of sensors, and everything else zwave including the light switches. I have a separate wifi installation for the usual entertainment stuff. A cellular panic button for medical emergencies. And a separate nonST commercially monitored alarm system. But I’d certainly consider zigbee or Bluetooth or whatever for any individual device that had specific features I wanted.
I know a lot of people want to mix security and home automation under one controller. Because cost is a big issue for me, I use cheaper mesh networks for home automation and pay more for a separate security system. As a quad, I need to know the emergency monitoring stuff is very high reliability and I’m willing to pay more for that.
So again, it all comes down to your particular needs. Just because one protocol is typically better than another for a common use case doesn’t mean it will be the best choice for you.