Actually not totally true. There was some content in there. But since it wasn't structured that well it's hard to see. Putting everything in a process is like putting your code in a class. It's not absolutely necessary but helps structuring stuff.

A process is a regular activity that solves a certain problem for a certain consumer group (the consumer may be an employee of your company, e.g. when the process is mail hosting for your company). Writing down the usual steps to take helps people to not forget stuff when doing the job, and helps managers/QA make sure everything is there to close a task.

Also each process has typical roles, e.g. someone who is responsible for the process adding value to the big picture (process owner), someone who is responsible for getting the day to day problems out of the way (process manager), and someone who actually does the steps involved in the process (process practicioner). With this structure it is easier to see when something is missing. E.g. in corp life one can often find a process with more than one owner, more than one manager, but zero practicioners, which results in nothing getting done at the end of the day.

Also you can think about how all that may relate to Scrum and co. There you also have these roles like board owner, scrum master and engineers.

All this stuff is somewhere in the article, but it's not layed out very well. Probably written by a person who works on a daily basis with people who already know all that, which of course makes the tutorial nature of the article worhtless. One may guess there was a blog post practicioner, but no (real) manager.

I was looking for more. I feel empty now.

confirmed, zero things in article