I'd suggest a different perspective from the one exposed by @David Chassels#. In my opinion, low-code and non-code BPM tools have advanced enough in recent years to be able to automate any real business process. That is, from a strict process perspective, there are no limitations to implement it without writing a single line of code.
From the integration point of view, there are no major limitations either. Of course, a bit more technical knowledge is required here, for example, to invoke integrations via Zapier, or WebServices. But as in the previous point, they can mostly be achieved without coding (some exceptions ahead...). This increases organization agility, and it gives breath to IT departments (specific
blog post
about it).
Where I think there is a difficult gap to close is in the user interface (UI). Here, it is practically impossible to design an interface that is highly customized to the organization, without coding. The better low-code BPM Suites provide simple, agile, friendly and beautiful user interfaces. That way, they mitigate the fact that they are not exactly customized to customer needs. Fair enough in many cases, and that's why this kind of application have grown so much lately. But it's definitely not enough in all cases. In particular, when complex calculations and transactions are required, it is difficult for the interface generated automatically by a non-code tool to be really good. In the same way, if integration with other systems cannot be solved by WebServices, you will also be in a scenario where the low-code tool will not meet the needs of the business. In those cases, custom development will be necessary, which will be integrated with the process engine.
In short, radical extremes are always bad. Currently, there is room for both. Low-code and non-code applications accelerate the digitalization of processes. And there are also scenarios where these tools are not enough and traditional custom developments are required.