Processes appear to me as the defining attributes of any corporate environment. It's basically in anyone's mouth and always come up as a first-citizen solution, whatever the issue at hand. "We'll put a new process in place for escalating customer's complaints", "We have been designing a new process to handle testing", ... And processes are not evil per se, at least as long as they streamline the resolution of the issue they aim to solve. Which, in my experience, is where it usually falls short.
You often hear about processes after the fact, usually when one did not follow it. "This would not have happened if you had followed the official procedure". And what is the solution to a broken process? Yet another new process. Going from there, it makes sense that some start-up jump on the opportunity to try replacing processes with technical solutions. Because designing a process is actually not too far from designing a program.
Yet, one can get distracted and focus on fixing the process instead of the original problem. I have been victim of this fallacy myself, and the main reason I came up with to explain it was that you usually do not experience the underlying problem. It feels that it is the process that gets in your way. And sometimes,, you do not even run into it. You may come across another's team process and think that it is flawed and waiting for you to come with an amazing automated solution. That's maybe where code differ from processes: code does not usually gives itself naked. It is surrounded by context and history that you can usually browse at will to build yourself a better understanding of the timeline and constraints that led to this design.
My early mindset revolved around trying to fight processes and replace them with some kind of technical solution or automation. I now try to favor communication and investigation to reveal the underlying problem that the process was trying to solve. And sometimes, a broken process may still be better than a broken program. Because human communication is a complex issue that cannot always be fully encapsulated in a rational specification.