Currently I am using homemade sort-of-framework for my pet projects. It has one big advantage - there is no need to learn API from external documentation as I am building it along my needs. I also learn a lot about reinventing wheels.
I disagree, unless you consider using a language to be inherently creating a framework.
Frameworks are generalizations, intended for flexibility. Their abstractions exist, typically, to shield a developer from the lower level stuff.
If you're writing plain ol language of choice code to do a specific thing, it's none of that. People can look at your code and see, oh, he's using built in cookie management and headers and standard language database calls.
It's readable, non abstracted code.
So a good programmer will start to abstract those things, and at that point you're going down the road of creating your own framework.
I think you're defining it way too broadly.
When I started learning PHP, I approached it the same way I do with every new language, I add a second file and use it for generic functions. I do it the native way inline as part of the main program flow, and then whilst ad-hoc refactoring (as I learn the language a bit better) I break out repeated chunks of code as a callable function and put in the second source file. I then re-use that second file for my next app in that language. Over time, I end up with my own personal framework. If I realise that I have a complicated function in my framework for which an inbuilt function or command exists (that I wasn't originally aware of) I'll refactor again and remove that function from my framework.
Doing it this way just made sense to me. The first time out with a new language is quite slow, but once I know what I'm doing, I have a bunch of useful functions on tap for each new project. It's a massive time-saver and conforms to the DRY principle.
Is what I'm doing 'a framework' really? I don't know, but to me its my workflow and I like it.
I also write PHP in a 'code behind' sort of way, with all HTML in separate template files, but I think that's a step too far for most PHP people ;)
Tbh, I simplified slightly - depending on the language, I can have many support source files full of functions, separated based on function type - so networking, IO, calcs etc.
For what I do, throwing up Slim, Guzzle, and Doctrine works well. You could make the argument that any one of those individually is a "framework", or that collectively I've made a new framework in 3 lines of composer.json by combining them. Point is many (and the article suggests) see framework or no framework as some massive all-or-nothing choice, when picking the parts you want, even after you've built your system out, us also an option.