I've used Construct for many years but I've never used containers. I've been using hierarchys once they were added, but before this I'd link objects together by having a parent object, with all the children having an instance variable that stores the parents UID.
I still use the "store the parent's UID" when it comes to arrays and dictionaries, as you cannot add an array/dictionary as a child with hierarchys.
We all learn in different ways - I am the type of person that, when starting to use a new software, I only Google/check the manual if I get stuck on the specific thing I'm trying to do, but beyond that, I wanna click and poke around the software myself - even if I click the wrong thing, I will learn from that. As months go by, I become very familiar with the general layout of the software, and THEN I read the manual more casually, so that I can see if there's shortcuts or secrets to enhance my use of the software.
I have somehow never used containers in all these years - I see the manual mentions at the very bottom about how you can use containers to store an array/dictionary per object, which sounds VERY useful!
However, I'm not fully convinced that containers are "adaptable" enough. I have the view that containers are for relatively simple situations.
Like let's take Scirra's example with the tank object with a separate turret, both placed into a container. Now say you design your game to allow you to upgrade your tank to have a 2nd turret - I assume that containers wouldn't be good for this situation, since you must stick with your original container setup and not edit this at runtime?
You'd need to specifically clone the tank object so that you can build a new double-turret tank (then put all the tanks in a family to make it easier to handle the tanks in events) which would work fine, but then you want to have a 3rd turret upgrade - again, clone the tank, and then make a triple-turret tank in the family.
Now this sounds messy, you wouldn't want to drive around in your tank, collide with a "upgrade" power up, and suddenly your events would involve creating the upgraded tank on top of the old tank, angle/position all the values from the old tank to the new tank, then destroy the current tank... Not very elegant. Maybe you could have an invisible "player" object that handles movement and everything, and the tank simply positions on top of the player object, but you still have to transfer some data to the newly created tank as you don't want your old turrets suddenly angled the wrong way when you collect the upgrade.
Sounds like a pain! But if you used hierarchys, you can have the 1 tank object, add as many turrent children as you like in different positions easily (which can automatically follow the tank along with the angle, width, height, z elevation), maybe store a variable for the turret like TurretID or use the IID when picking the tank's turret children, so that you know which turret to pick when you wanna do stuff in events, and then you're done! If your tank needs a different shape, you can add an animation for that, so you never have to destroy your tank object at any point.
The final downside to containers, is the lack of control over destroying everything. Bad example, but let's just say you had a situation where your turret should destroy on its own for whatever reason - Well you can't do that, as it will destroy your tank entirely. You would need to set the turret to be invisible I suppose, maybe that's better design anyway, but hey I wanna destroy it and I'm not able to!
Please correct me if I'm misunderstanding the true power of containers, as I'd rather understand this better!