Counterexample: MS Access apps are often a maintenance nightmare.
They end up being a maintenance nightmare because they are undocumented and flooded with poorly written VBA, which is hardly low-code. A non-VBA Access Database is trivial to maintain, but VBA is a full programming language, so if that's heavily used it's really maintaining a VB6 Winforms application, which isn't what we would now typically call 'low code' in terms of this article.
(As an aside, I would actually personally argue that a completely undocumented MS Access database is actually slightly easier to maintain than an equally undocumented web application anyway. The reason these tend to be a 'maintenance nightmare' is that they are typically made in Shadow-IT rather than the technology itself which is very simple).
Low-code and no-code solutions are often created by shadow-IT.
Heck, while it is phrased differently, enabling Shadow IT is an explicit selling point of low- and especially “no”-[0] code tools.
Of course, Shadow IT isn’t the tools fault, it is the organization that segregates IT into a separate heirarchy often the whole way up until the C-Suite.
If IT was a function integrated within each business unit empowering it, rather than external silo alternately constraining arbitrarily and granting favors, Shadow IT woudn’t be a thing. Shadow IT is a symptom of a broken relationship between IT and the broader organization.
[0] but often not really “no”, just as Excel isn’t.
In that case the issue is Shadow IT then, not low-code tools.
We used to call those data entry screens "HTML forms". And hey, they're even text based so you can commit them to a version control!
And although it's easy to write a HTML form, it tends to be slightly harder to write the code handling it on the backend to change the database, with full user/roll based authentication and validation - particularly if you are integrating it into your ERP.
If the use case is a form to interact with Microsoft Dynamics, something built in PowerApps model-driven apps will be much more robust, quicker to develop and more secure than a html form with some custom handler.
The reality is that some problems are fundamentally better suited to low code, and the solutions will be much simpler and easier to maintain if they are built as low-code (e.g. if I have MS Dynamics and want a new data-entry screen, doing it as a model-driven PowerApp is undeniably the best way to do this).
Other problems will either be too complex, a poor fit, or simply not possible to implement within low-code tools. I'm not going to start developing a mobile game in PowerApps!
I think the overall issue is "If all you have is a hammer, everything looks like a nail". The best thing is to recognise the relative strengths and weaknesses of the two approaches and pick the right tool for the job.