The question was how your solution is better than a hosted logging solution. An "automatically pulling in state and logs for associated nodes" requirement is achieved in cloud log hosting by placing tags on the logs. This tag and this tag are correlated, so show these things to the user, for example. This is accomplished with a search engine. This is assuming all data is sent to centralized storage.
I was, in part, responsible for creating a cloud logging service. I've never heard the term "lifecycle events" before, but it sounds like something where a device has a life and over time it has events occur, some of which are logged, and some of which are not. Whether or not sending these logs in a controlled way or not would not seem to matter much if the logging was aggregated in a centralized location. The "benefits" of not sending all log data from a device are not presumed to be that important, given bandwidth is cheap and storage even cheaper, increasingly over time for both.
Controlling what information is and is not sent from a device might be interesting (assuming correlation with this and this device, log to here), but you can't depend on the device to have the room for storing that stuff for long, or having much intelligence in sending it on (unless you run something like Particle's devices which have some cloud connected logic built in).
A dedicated edge device for this task might be interesting, but some IoT use cases won't have those edge devices available (at least for some time) on customer premise (home?), so logging to the cloud is presumed to be the only solution here. This reminds me, Microsoft just released some IoT stuff recently that may be related.
The question for how your product compares to existing cloud logging solutions will continue to resurface for y'all. Figuring out a good answer to that may make all the difference in how you go to market!