Building good software requires a modicum of process to ensure quality and being on point for delivery. Too much process is bad. Too little process is bad. Poorly followed or atrophied process is potentially worse than either of those individually.

I have observed again and again that no matter what processes, how heavy handed or not, are in place, there is a tendency toward entropy in the application of such processes. In the majority of software development lifecycle workflow patterns there are many patterns and they all suffer this same challenge daily as time passes.

Examples:

Assigning Story Points / Effort Scoring in Scrum or Kanban flows - Estimating is art more than science sometimes but deeply important.
Sprint Planning in a Scrum flow - People can get a little worn out sometimes with the rigor involved in full-one scrum/agile. However, these processes exist for a reason. Just one time style missing soon turns into project and technical debt that eventually has to be repaid.
Checklist processes - You spent the time to make the checklist. You know exactly how to use it but again and again I see them gathering dust. This is true of meeting checklists, launch checklists, etc.
Launch Rehearsals w/ adherence to NO GO if things don't go well. This can save so very much pain. People are people, we get tired, busy miss things. Running through the paces in staged rehearsals can combat this mightily. Skipping this process generally leads to lots of lost sleep and bad feelings.
Testing Falling by the way side - We've got loads of tests. You don't always need them all. There's functional, QA, unit, load, etc. However, just skipping testing is a true recipe for disaster when it's truly go time.

and more...

In summary, as noted, too much process is simply not good. But, nothing is just a different kind of mess. Letting processes you spent perfectly good time and effort to create and learn atrophy is a bit of a crime (as would be doing them blindly of course). It's up to the active team to lay in the right processes, in the right amount, at the right time to make sure that a quality, timely, cost controlled, high estimate tolerance outcome is achieved. Ironically, NOT trying to plan every tiny little detail up front is one of the real keys to all of this but it only works when there is room to move. Lastly, everything is always in motion. Just like code, processes need to be refactored over time.