Disclaimer: I'm approaching this from the automation side, and currently work at UiPath.
What do you want to use your low-code system to build?
If you're targeting arbitrary app creation, then you probably want your aforementioned tools or the myriad of other options (e.g. Appian, etc).
But if you're targeting automation of existing processes / apps, on Windows, and would like some-but-not-unlimited UI flexibility... use an RPA tool. E.g. UiPath
You get out of the box GUI integration for driving other apps + all the other app designer bits.
Which turns any automation problem into (1) "Is there a prebuilt component for it?", (2) "If not, can I interact directly with the necessary GUI controls?", (3) "If not, can I use CV to drive the problem GUI sections?"
In ~10 years of doing this, over a few products, I'd say (1) handles 60% of use cases, (2) handles 35%, (3) handles 4.99%, and I can only think of a couple times I've fallen completely through and been unable to automate.
And which, critically, means you can push the tool to non-traditional programmers and get decent results.
---
> Can you do an effective SDLC with them? E.g. code on a staging environment, push to version control, promote to prod, rollback to old version
Go ahead and ignore any tool that doesn't store apps/automations in readable files (typically XML).
From that subset, they have varying CVS support, but most modern ones support a sane SDLC.
I'd also weed out anything that doesn't support command line / Jenkins builds.
> Have you actually saved time with them?
Hell yeah. I've automated health care EMR and claims systems in a few weeks... that I'd still be trying to get legal access to an SDK if I'd gone that route.
The key feature of RPA is WYSIWYG automation: since you're automating your GUI, there's no impedance between {process as performed by user} and {process as performed by code}. You just ask them what they do, then 1:1 map actions to automation.
> Did you avoid introducing unworkable complexity?
The key here is process documentation. Specifically, writing down the why of a process and its steps. What is more typically noted, but is far less informative.
With the why documented, you can port to an alternate system or adjust the process down the road without issue.
Setting up hard, machine-checked "must X to Y" gates helps a lot with ensuring consistency here. E.g. carrot and stick "you must create a doc in this format, have it reviewed, and have your code in version control and reviewed" before "you get the ability to schedule it in production"
If you want lessons-learned from my adventures (and misadventures) of creating a low-code offering at a large enterprise company, feel free to reach out. Email in profile.