I will just write here my usecase where Webinoly is perfectly safe and has enough isolation. I provide people with managed Wordpress sites. My promise is: I take care of the code, you take care of the content.
I manage all the plugins and cores with wp-cli and I take advantage of the possibility of writing scripts, to help me with that. I as a unix user am the owner of all of the code, so www-data can't write to any of the folders except for the ones where php is disabled (Uploads and certain languages folders).
This makes my stack pretty safe but it also disables the possibility to install/update themes/plugins/core from the wp-admin section, which is ok with me, since my clients only want to control the content, while I use wp-cli for that.
For this matter Easyengine before, and now Webinoly is the perfect tool (with the exception of one patch I have to make). The official Easyengine 3 fork called WordOps has several downsides compared to Webinoly: the development is less dynamic, it still has some caveats easyengine was struggling with and, crucial for me, it is written in python. It would only make sense to me, that a script intended to manage php sites would be written either in php or in bash. I don't particularly love bash, but it has an upside of being easy to understand.
The one upside of WordOps is a bigger company and team behind it, making its development more stable in the long term. Webinoly has bus factor = 1, meaning if QROkes gets hit by a bus, we are all screwed. However, since the code is pretty well organised and neat (kudos to QROkes for that!), forking and maintaining it wouldn't be as much of a problem.
This is why Webinoly is usefull, secure and makes sense to me. It all depends on the usecase, how you work and what you want.