There would be far fewer bugs if people actually stick to writing code like that.
I once had to reverse engineer (extract the spec from the code) a C++ function that was hundreds of lines long. I have had to fix a Python function over a thousand lines long.
I am sure the people who wrote that code will find ways to make life difficult with Rust too, but I cannot regret having one less sharp knife in their hands.
On the other hand, parceling a large function into smaller functions can create indirection that is even harder to follow and harder to verify as bug-free.
Maybe, but it usually has the opposite effect. If you have well-designed and named functions the indirection is a feature since it reduces the amount of context you need to remember and gives you a visible contract instead of having to reason about a large block of code.
This works if you know what each callee performs, which you frequently don't when you're visiting a new codebase (it may have an unknown function you have to read to know, functionality not relevant to your problem, or you may have to analyze two or more functions in the context of each other to understand a bug).
I once had to reverse engineer (extract the spec from the code) a C++ function that was hundreds of lines long. I have had to fix a Python function over a thousand lines long.
I am sure the people who wrote that code will find ways to make life difficult with Rust too, but I cannot regret having one less sharp knife in their hands.