It's also because knowing where the escape hatch and how to use it requires greater than average development skill and finesse and it isn't at all obvious when this is required.
The people who use these platforms aren't usually able to tell what kind of problem requires a developer and what kind of problem requires them doing just a bit more research. They're usually vaguely aware that the limit is out there somewhere but in the specific instances when they hit it they often don't know it's happened.
I've also seen some low code platforms get a little excitable about the idea of nearly or even fully reinventing the turing complete programming language to introduce more flexibility to their platform and make that their escape hatch. This is when things go really downhill.
Per end user rather than per developer means they're far too expensive to introduce as a general IT toolbox item, they need to be part of a major strategic project where the $5-30/month per staff user has a hope of being justified.
But that also often takes it outside the "IT Dept", which is often just "infrastructure and pc fleet" support, not development ( at least, that's my experience ). IT might do internal scripting and some service interface tooling, but business tooling and software is rarer, that's usually either dev teams or ERP teams. The ERP teams will already using ERP platform tooling, so that further narrows the market.
I don't have a good solution for this, but it's always been the hurdle I've tripped on working for medium size enterprises.
There would seem to be an opportunity for "open source platform, commercial training and support" here, but vendors seem to gravitate to per user head and cloud only for more immediate revenue and easier support., but again many enterprises still have huge internal only IT landscape's, because cloud is still expensive and the value often isn't seen in relatively static envs.
It's possible this niche has been filled now too, it's been a while since I looked...
Possibly they can be introduced on a "just those who need it" basis, but honestly that's just so bloody tiring for internal tools, not to mention demotivating as you can no longer build tools for "everyone or anyone", it's back to specific narrow business cases, not IT empowerment, but narrow business case also means your usually competing with cots tools or consultants.
All the components and modules that low code tools provide should be nothing more than an onboarding tutorial like the first few levels of Factorio, before letting the engineering team loose hand in hand with the users. It shouldn’t be an escape hatch, it should be the front door.
As such all these low code tools make the mistake of making it really difficult to bring the engineering team into the fold: modularization, logging, debugging, version control, and development tools are absolute garbage so instead of engineering providing a few sane company specific building blocks that they can tend and nurture, it inevitably turns into a shitshow because you can’t use a tool that ultimately depends on the IT department to fix the IT department!
The best “low-code” tools have already been around for over a decade: it’s the headless CMS and autogenerated admin pages ala Django and Wagtail. They’ve been focused on solving the content management problem for e-commerce and marketing, but IMO it’s the write path for other groups too. The engineers write the pages and blocks and components while defining an input/configuration schema for an automated tool that is usable by laymen. Up the level of abstraction to a well curated (by the engineers at the customer level) IFTTT layer and bam, you’ve 95% of use of low code without the 5% that inevitably ruins it.