Agreed. One additional source of disconnect in discussions is that the appropriate amount of process varies depending on what your goals are, your team composition (seniority, personality, communication styles, etc.), your regulatory environment, and myriad other factors.
If you're early-stage Facebook or most consumer-facing recreational apps, "move fast and break stuff" with minimal process is great, since the potential downsides of pushing a bug to production are usually far outweighed by the value of iterating quickly. You can trust your developers to do the right thing, because for the most part developers will, and on the rare occasion that someone doesn't, the consequences are not severe.
If you're Signal, or a FinTech company, or NASA, or a medical device company, then you need significantly more robust process to ensure that appropriate quality control, chain of custody, etc. is being applied at each stage of the process. Trust alone no longer works because even though it will get you the result you need _most_ of the time, that is not a high enough success rate.
Put more generally, more/improved process is required when you cannot tolerate a given failure rate, and in general you trade off throughput against failure rate.
Having said all of this, many companies cargo-cult Google and add process when they don't need to raise the quality bar, or implement poor process that fails to increase the quality bar; these would be examples of bullshit process as the GP puts it. However I feel like we're often not presented enough context to disambiguate appropriate process from BS.