Perhaps the most serious limitation is the tendency for large procedural-based programs to turn into "spaghetti-code".
Spaghetti code is code that has been modified so many times that the logical flow shown in the figures above becomes so convoluted that any new programmer coming onto the project needs a two month prep-course in order to even begin to understand the software innards.
Why does this happen?
Well, in reality, a programmer's job has just begun when she finishes writing version 1.0 of her software application. Before she knows it, she'll be bombarded with dozens of modification requests and bug reports as users actually get to batter and bruise her poor piece of code.
In order to meet the demands of the evil user, the programmer is forced to modify the code. This can mean introducing new sub loops, new eddies of flow control and new methods, libraries and variables altogether.
Unfortunately, there are no great tools for abstraction and modularization in procedural languages...thus, it is hard to add new functionality or change the work flow without going back and modifying all other parts of the program.
Now, instead of redesigning the work flow and starting from scratch, most programmers, under intense time restrictions will introduce hacks to fix the code.
This gets us to the second problem with procedural-based programming. Not only does procedural code have a tendency to be difficult to understand, as it evolves, it becomes even harder to understand, and thus, harder to modify.
Since everything is tied to everything else, nothing is independent. If you change one bit of code in a procedural-based program, it is likely that you will break three other pieces in some other section that might be stored in some remote library file you'd forgotten all about.
A final problem with spaghetification, is that the code you write today will not help you write the code you have to write tomorrow. Procedural-based code has a tenacious ability to resist being cut and pasted from one application to another. Thus, procedural programmers often find themselves reinventing the wheel on every new project.
Procedural-oriented programming is actually very powerful, so
don't let the hype make you think that it has no place in your
arsenal of programming tools.
Like libraries, languages, and toolkits, methodologies are just ways to solve certain sets of programming problems. There is no such thing as an all - powerful methodology. In some cases, the object-oriented approach will be best suited to your needs and in others, another methodology might be more appropriate.
PS: A well written procedural-oriented program can actually be easy to understand. It is just that well written procedural code is hard to find, especially when 'teams' of programmers, working on multiple versions are involved. The fact is that procedural languages typically lack the syntactic sugar necessary to enforce abstraction.