Well then, I guess that's all the more reason to support returning created objects from functions. ;) I mean honestly, simple games are perhaps okay, but more complex ones need to create functions to encapsulate some kind of shared functionality - object creation for example, then return it for usage - and this is especially true when there's no way to group sprites (treated as single entities). Having to "pin" via code is not good practice for an IDE of Construct's caliber. At the very least, if I have to pin objects to objects via scripts, it would be nice if I could at least wrap that in a function, which returns the object for use. For functions to be really useful beyond simplistic games, they need to encapsulate some functionality that can be "applied" and reused for various objects. Either a function needs to accept certain family types as a parameter so the function can apply some state values, or other functionality, or it needs to support returning them.
Example: I have a space drone. It has a "shadowing" sprite overlay, and 4 line of sight sprite overlays. I have to create all this, AND PIN, via a function. To make matters worse, I have to dump them all sprites onto a layout before I can even use them. The "line of sight" sprites can be used by many objects, so I tried to encapsulate the creation in a function, and got the issue above. Now, I have to duplicate my efforts for each object, which makes the functions useless for their expected functionality (to reduce repetitive scripting).
If functions are made a bit more powerful, it totally makes up for a lot of other stuff (like lack of grouping as mentioned earlier). ;)