I think you'll find a fairly high percentage of "#5, Other", because the list is missing one of the most common consumer IoT architectures: indirect communications via an in-home gateway.
All the other methods you describe have drawbacks in the home: they're hard to configure, they're not secure, or they take a lot of expensive server resources. An in-home gateway avoids those problems for the individual devices, exposing only one device to the internet.
The typical gateway serves several purposes. First, it's a protocol bridge. Wireless devices use all kinds of open and proprietary communications protocols, including Z-Wave, Zigbee, dedicated 900 MHz RF, dedicated 433 MHz RF, infrared light, Bluetooth, BLE, ANT+, Crestron, etc. These solve all kinds of niche problems, like per-device cost, battery life, self-configuring mesh networks, rapid response times, insecure communications, simple configurations using minimal storage, etc. This way most consumer IoT devices aren't using IP packets, but instead deliver their data inside much smaller frames in order to preserve battery life. The gateway will convert the proprietary protocol into something more transportable and interoperable with an IP based network.
Also, the in-home gateway is a good place to store the rules of the system. If you're going to enable rules like "if you turn on the light at the top of the stairs, also turn on the entryway light, unless the kitchen light is on," you can place the rules in the light switches, a centralized web server, or the gateway. Putting the rules in each light switch makes for a brittle configuration that's hard to set up, change, or manage. Running the rules in a centralized server introduces latency because the message has to be translated to TCP, encrypted, sent across the internet, the action has to be received, decrypted, and translated back to Zigbee. The gateway enables the vendor to solve these problems by providing a single management point to back up and restore, and local processor to run the rules quickly.
Security is a big issue: IoT devices need to be cheap, and cheap processors don't have big CPUs and storage for secure encryption functions. Not to mention the desire to avoid the massive expense of developing securely encrypted protocols. So they implement very weak (cheap) security in the consumer devices, or no security at all. They make up for this by only communicating within a very limited range - they only have to reach the in-home gateway. This way, the gateway handles the local unsecured communications, and only one device needs the processing power and storage needed to communicate to the cloud over TLS.
Finally, the gateway can provide a convenient single point of human interface to the devices. Most gateways expose a web interface, allowing for GUI-based configuration. Imagine trying to Morse-code-configure a 12 character WiFi password into a device using only one button and one LED. Worse, imagine your company's phone support staff talking each customer through that process.
Unfortunately, this still does not answer your question directly. But I expect the gateway architecture to be the most common way consumer-oriented devices connect to the internet.
EDIT: In response to your comment about in-home gateways used for IoT devices, there are a few basic kinds: dedicated single purpose, dedicated multipurpose, and general purpose. In addition to the interfaces below, all of them have an Ethernet or WiFi interface to bridge messages to and from an IP network.
A dedicated single purpose gateway speaks only to a particular manufacturer's devices. The simplest examples might be a USB dongle that receives data from a single device, like a Fitbit dongle. Other examples include the Philips Hue Bridge (which communicates only with Philips Hue light bulbs); the Liftmaster MyQ Gateway (which communicates only with Liftmaster, Chamberlain, or Craftsman garage door openers); or the Harmony Hub (which communicates with Logitech Harmony remotes and blinks IR to various home theater components.)
An example of the dedicated multipurpose hub would be Samsung's SmartThings hub. SmartThings sells a wide variety of home automation devices, but they only speak the SmartThings protocol. The SmartThings hub can also communicate to many other device controllers via IP, and has native IFTTT integration.
The general purpose gateways may have some proprietary components, but often support multiple interfaces and can serve as a primary smart home interface. Examples include the Wink Hub (which communicates to Zigbee, Z-Wave, Lutron, and Kidde RF devices); Vera Edge (which communicates to Z-Wave and Insteon devices, and extends to communicate to external devices).
Finally there are also some very active open source efforts in the general purpose home automation domain, including Domoticz and OpenHAB. These are software programs that support communication to IoT devices through dedicated bridge devices (such as a Z-Wave USB dongle or a Zigbee radio), implement rules, and offer extensive integration capabilities such as IFTTT, MQTT, and others.