You can think of the webCoRE dashboard as a kind of integrated development environment where you can build, test and monitor pistons. The pistons are effectively compiled into ST Groovy SmartApps which plumb into the ST Cloud. The plan is that instead webCoRE should become an IDE building rules for the ST Rules API. All the logic would be implemented by the Rules API and not by a SmartApp.
The plan is that most things that webCoRE can do now, it will be able to do in the future, and it helps that the author of webCoRE is working for SmartThings now.
I haven’t looked at the Rules API too closely, mainly because at the moment it is pretty basic and it seems to me that there is a way to go yet. You can do a lot building on simple conditionals, but where webCoRE scores is being able to adapt to real world requirements by stopping things happening. For example, new users to webCoRE tend to quickly encounter the Task Cancellation Policy (TCP). Imagine you have a light come on when open a door. Once you’ve closed the door you want it to stay on for 30 seconds. That’s pretty straight forward logic. Now supposing you quickly open the door again. Do you still want that light to turn off after the original 30 seconds? By default, webCoRE will assume you don’t and stop it happening, but it will also allow you to decide how you want it to behave. That takes a lot more complexity.
My personal opinion is that you’ll always want to abstract the Rules API using something like webCoRE, or SharpTools, or anything else that comes along.
If you have something you can host your own code on, like an RPi, then you can go down the SmartThings API route (https://smartthings.developer.samsung.com/docs/api-ref/st-api.html). So code your logic in your choice of language and interact with ST by REST calls.
Depends what floats your boat really.
