Judging from the URLs, it seems that each action is handled by a different standalone script. This is very common in legacy code bases, and it typically (not always) means that:
1) all those scripts need the same bootstrapping boilerplate copy-pasted into them, which is a maintenance nightmare. Even if you simplify it to one or two lines of boilerplate that includes a central boostrap file (or use some configuration magic to automatically run an additional script before the script you requested), it's still worse than having a single centralized entry point that handles routing, auth, and so on. There's always a chance that someone forgets or botches an auth check in one of these files and it goes unnoticed.
2) you will probably be able to make an HTTP request directly to some file that was not intended as an entry point (the author mentions header.php – this is a perfect example), and then who knows what happens, because you never planned for this and your bootstrap code doesn't run and possibly variables expected by that script are not defined, or errors thrown by the script are not handled by a pretty error handler... kinda like doing an assembler jmp into the middle of another function, after any sanity checks it might have had.
3) I have been working with PHP for 8 years now, and almost inevitably, where this pattern shows up, there's most likely outdated and insecure practices like SQL queries from string concatenation (leading to SQL injection) or unescaped HTML output (leading to XSS, XSRF, or other security problems). It's basically an "easy target" sign for hackers.
Front Controller pattern [1] is a recommended alternative.
If you combine the article's findings with this observation, one could foresee sending a crafted /footer.php?args=SQL+Injection+goes+here type request that skips past where input is "sanitized" and results in code injection.
(Further details are NDA'd, but I've found similar issues before in production systems.)