As someone who has been managing Low Code/No Code on a large scale for a major enterprise from before this became buzzword soup, I can categorically state that the benefits are real.
HN isn't the intended market here, and that disconnect is shown in the currently leading comment thread which is talking about DevOps deployment. DevOps is way beyond what this space currently targets and is working to achieve.
To be crystal clear, Low Code/No Code is not going to replace a company's custom developed application that drives their core business. It isn't even going to replace the need for custom application development throughout an enterprise. This is an augmentative technology stack intended for a different audience.
What it does do is empower non-IT employees to become what the industry likes to call "Citizen Developers". Think more Excel/Access less .
Where this technology currently shines brightest is at the lowest levels of work. Every enterprise has pockets where work is getting done from Excel spreadsheets, Access databases, email chains, SharePoint/Office documents and worse. Essentially work that could be done easier and better with an application, but where the current enterprise cost, developer availability, political/agility issues, or simple knowledge that the problem exists prevents that application from being created.
The best products in this space allow IT to setup a space where non-IT staff can create applications within the confines of the environment to address these problems. For example, a department can go in on their own and replace a shared spreadsheet that is locked all the time from coconcurrent use with something that is truly multi-user. On top of that, they get to enhance their process and improve productivity by having it generate emails to someone when work is needed, or automatically create new tasks when certain statuses are encountered, and other similar things associated with "modern" technology. They do all of this on their own without needing formal IT development resources.
There are obvious benefits to an enterprise here - like replacing multiple unsupported/bespoke solutions with a single known and supported platform - but there are multiple side bonuses as well. For an example of one, the best products in this space have great APIs. The staff making/managing these applications may not even know they exist, and certainly can't write against them, but now IT has a standardized way to get this data somewhere else when needed. Data driven organizations can use this to drive what I call "Small Data", which is applying Big Data practices/analytics to low level work product to improve processes.
The next major development in this space will be low code/no code integrations. When you're talking about these low levels of work, they are generally mid-process actors. Work comes in, gets done, and is handed to the next in line. That data largely gets to these teams from some kind of export process in the upstream system - CSV dump, daily email, etc. - and then needs to get fed back up via a similar or worse method. You can use the aforementioned API to fix this, but that again requires developer resources. This may be doable to for interacting with a core upstream system but it isn't always available when you have two bottom level processes looking to communicate.
The ability for "Citizen Developers" to be able to obtain the data they need from an upstream process, complete the work on it inside their application, and then return the results back to the upstream process or next process in line without having to write code or otherwise manually intervene will further drive productivity and usefulness in this space.