To be perfectly honest a lot of people don't understand how the more low level parts of a game engine like the game loop usually even work, my thoughts would be this whole action system thing developed as a way of hiding away all that code to make it simpler for a wide range of coders. You are talking about a framework for 2d games, not the deep down code of a massive engine like source or unreal or something. XNA hid its game loop as well if you used the base game class.

I haven't actually used any of these "action" things but taking a peek at cocos it seems like it would be pretty standard behavior you might implement in a game anyway, movements or color changes to sprites either instantly or over a period of time, based on the code it seems like a bit of a soft excuse for them to have hidden the core game code away in some singleton instance. At the very least they'll be tracking time and doing a bit of a mini-loop somewhere to actually advance all the actions and things anyway.

Is it good or bad? I don't know, I guess that's in the eye of the beholder, it probably makes things a lot more accessible in the same way that Unity has severely lowered the ceiling for coding ability that you need to throw together a game. Personally I'm more interested in down to the metal access and is the main reason I stick to libraries like SFML instead of frameworks that abstract everything away for you without any control. Why? Main reason is you learn a lot more, there are quite a lot of projects out there you might want to attempt someday, or working with others, that require someone to know all that down to the metal implementation information.

If you're going to USE cocos I would say you'd probably make your life a lot simpler to prefer their methods to what you're used to, unless that isn't -enough- to do what you want to do. I'm not that old really but to be frank I would say there is much more of a divide growing between code that would made by someone able to develop a full fledged engine for a game, and someone who does nothing but script for middleware.

Develop a game faster but have a much lower ceiling on your knowledge, or take much longer but have a greater depth of knowledge. Seems to be a wide divide these days.

I used it in cocos (long ago) because I didnt find any other means to control the stuff (like animations) tightly.

I hated it, it requires a bunch of loading code to prepare the actions, and when you need to interrupt it, cancel in the middle or something, it gets even more ugly. ( I dont remember very well thou)

In my engine, I have chainable tasks, the purpose of those (from my POV of course) is to use it when you need to execute some code that would be a rare if case in the game loop. Basically, having a loop full of IFs that almost never execute is ugly/poor code, so the tasks works perfectly for stuff like this, since in the game loop is just a tasker.update(delta); call. So I use it as a temporary code executer.

One of my tasks is a "delegate task", that basically executes a delegate till it returns false, making it very easy to create new tasks without having to derive a new class (just create a new method and plug on the delegate).

Chaining tasks is not as cute as I though it would be when I implemented it. Reusing tasks by reordering the chain is not so obvious and generally I end up with a few small tasks that are almost the same.

The fact that I prohibit myself from allocate memory at run time also requires pre initializing all tasks, with is also a pain in the ass. The task machine works with shared pointers so I basically initialize a bunch shared pointers with noop deleters.

Are you seriously saying that that is not common?

That's how I like to do it. However, Qt, being a desktop application GUI toolkit, wants to control the main messaging loop for me, so I have to write my code to react in response to callbacks. Not too much of a hassle, since I still have React(), Update(), Draw(). Having dozens of different callbacks that I'd need to react to would be annoying, depending on how high-level the API is.

I'm not sure what your issue is exactly. Spritekit already has methods for:
update <---- This would be your game loop
evaluateActions
simulatePhysics
finishUpdate

These are called every frame. You don't need to use actions to control Sprites you can actually set the properties manually in the update method of your scene:

mySprite.scale = 1.2

Apple actually mentions in some of the documentation that this is the recomended way of doing things and that Actions should only be used for one time canned effects or UI animation

Cocos2D has similar methods too. However all the tutorials out there people just tend to use the Actions because they are simple to set up. If you are doing anything more complex than a match3 or word puzzle game then just drop actions and stick to updating your objects manually.