There's a difference between frameworks and libraries and of course it is a good idea to use trusted crypto implementations and avoid NIH syndrome, but a large part of security is including it in the design process from the start.
You can't just assume "the framework will handle it", or "bcrypt is all I need" or "the opsec team will find all the problems".
It rather sounds like you're expecting the author to hand you a magic-bullet solution, which is rather the whole point of the article: there isn't one. You do need to know what you're doing.
However, a framework does increase the attack surface, which is something that should be taken into account. If you save 20 lines of code by adding a 100,000 line framework, you need to ask yourself which of those is most likely to contain a bug?
Plus, bugs in popular frameworks tend to get exploited in practise. Other bugs less so, because of the need to first find the bug. The odds of that happening will increase if the bug is common and obvious, or you are a particularly high-value target. By using a framework you effectively increase your value as a target to the sum value of all projects using that framework. This becomes especially bad if the framework stops being maintained, because the value to an attacker isn't lost as quickly.
The above also applies to libraries, but libraries tend to be more focused and more stable than frameworks, since frameworks tend to "go stale" if not continually updated in a way that most libraries do not.
"You can also find sober drivers that cause accidents". Of course, but it doesn't invalidate the fact that drinking and driving is a bad combo and puts you and others in greater danger statistically. It's sort of similar here.
It's kind of the point of the whole page - you don't need a massive general framework to solve your specific problem. Maybe read the whole thing instead of just skimming it.
And that supposes that not only you know about it, but also how to implement it properly. Not to mention the time to code it, document it, test it and maintain it.
Most custom PHP site I encounter are full of gigantic holes.
And then other developpers comes in, and have to learn how to use your non standard code, that is unlikely to be half as well written, tested or documented than standard solutions.
Of course custom code has also a cost, which means doing all that, even not very well, will take a toll on the budget, which you can't spend on other security aspects. All that while security is generally the last item on the budget list.
If you use a framework, new developers coming in often have to learn how to use it as well.
I've never hired a developer who didn't know how to use PDO prepared queries, which are the standard in my code base. Built into the language, escapes no matter what database you use, etc.
Good developers know how to write secure PHP code without a framework. They don't necessarily know how to use a random framework.
Bad developers will at some point take variables from a $_POST/GET array and use them unwisely regardless of whether you have a framework.
Basically, don't use a framework unless you really do need all the features it gives you. Don't just pick a framework and try to cram your code into it for the sole purpose of using a framework.
It doesn't matter how much lines you write. It has nothing to do with the number of lines but the functionalities and how many developers review that piece of code. Furthermore more a third party codebase is usually the code you don't have to test. You keep on talking about frameworks like it's a bad thing, but all frameworks are not equal in size nor features.
include 'vendor/autoload.php';
Including a package based on the contents of its packagist description alone is basically like reading the ingredients for a pizza and then eating a bag of flour.
But if you've built it on top of a huge framework then you can end up with all the separate parts stuck together in a massive project where you're not even using 75% of the framework.
1.- Massive project where you're not using 75% of the framework.
Let's say i don't want the template engine and the ORM, the framework should let me pull them out. If i need them at some point i'll pull them in. But i know that when i do, these things will be maintained and working.
And this is where a good framework shines. No need to deal with a dependency hell, and you should be able to pull out easily what you don't need.
Edit: If you're just using a 25% of a framework and have no prospects on using it maybe you should look for something smaller
2.- Separate parts stuck on a massive project
Thats not the framework fault but yours. You should write the parts of the application in a way that you can reuse them in another project, using the same framework or in a similar framework with as few changes as possible. And also its part of your work knowing a bit on how the framework works under the hood. The same way an android dev not only needs to know how 'generic' java works, but how android's java vm works.
3.- Those microservices may not follow a standard.
While frameworks allow you to write bad code, they kind of force you to follow some standards which reduce bad code and let other developers take on the project easily.
On the other side, a well developed microservice based project is usually better than an equivalent one that was based up on a framework. But it takes more time/work and has more risks (specially in php).
Actually it isn't, like at all. A open source framework will always be more secure than the code you "easily write", because a larger pool developers can review,audit,test and fix that code.
The code you do write is going to be more secure if you know what's going on. If it's on top of a billion line framework, you might accidentally break the security without even realizing it. No legions of framework developers reviewed, audited, tested or fixed your actual code.
It might save you time, initially. But at some point you will have to sit down and learn what the framework is actually doing behind the scenes (is it really secure? why is it so slow? I really need to implement this obscure, unsupported by my framework, thing), and you might not be so happy about your choice. Thinking about this ahead of time will save you headaches in the long run.
Think of PHP as sandbox programming. Such an open language, there is a lot of freedom, so many ways to achieve a specific result. The takeaway from the article is that "always do X" shouldn't be a thing, considering a) the vast possibilities and b) your purpose. Frameworks might be too much bloat, patterns should happen naturally, not forcefully. Security should be paramount, but it shouldn't be a blackbox behind third party code, you should be able to explain how you are protecting your users. Etc.
This is not a "don't use a framework/standards/etc" rant. I see it as a reminder to double-check if the current... trends/standards? match your actual needs and wants.
That depends on the scale of what you're building. Generally I would agree with you, but if you building some small, something that would only ever use a small subsection of whatever framework you pick, then you could end up having more issues than if you didn't use a framework.
Just because you aren't using parts of a framework, doesn't mean that security issues in the framework won't affect you.
Let's say your application only ever needs to do one or two queries to a database. It's going to be a whole lot easier for you to lock those two queries down, than securing an entire ORM.
If it's a competent ORM then it shouldn't even expose any way to not use prepared statements, for example.