That is, while there is value in the items onThere is a lot of value in the right process, the process however needs to be a servant to the needs of the people. You can be agile with long complex processes so long as you pay attention to how the processes affect the people and ensure that every time a process is getting in the way of someone it is a good thing.
I think we would all agree that process needs to stop the "cowboy coder" who otherwise would check in code with many syntax errors just before leaving for a long vacation. This example is nearly a straw-man it is so trivial - but if anyone doesn't have personal processes to prevent it the team will need to create a process of some sort. This could be a simple don't do that again talk, a HR process to fire the guy, a automatic backout process, a formal checkout for pushing, or whatever - the choice is up to your team, and depends on team factors like if this is a one time mistake or a repeated offense.
Going to the other extreme, medical software that could kill should have long complex processes. Agile is perfectly fine with this.
Agile is taking issue with some [big companies] that have created such long cumbersome processes in ages past that no longer serve the needs. Sometimes they created a complex process because of a one time mistake that is unlikely to happen again. Or maybe the process made sense in light of the tax laws that were changed in 1986. Some processes actually are required and useful, but because of all the cumbersome ones they are ignored until it is too late.