The line between unit and functional test is much fuzzier than the purists would argue. Generally speaking, the more contained something is the more tests it should have.

If you're building a library (which is most of the PHP I've been writing lately), the emphasis should be on small-unit tests. If you're building an application that is mostly just stitching together other libraries (which most should be), then yes, you'll probably have mainly functional/end-to-end tests. That's because the lower level tests are already written for you by the library author (who may be you, or not).

My current project is Tukio, a reference implementation of the in-progress PSR-14 standard for PHP. (That's where the examples in the article came from.) There's by design no external resources to think about (DB, etc.), so everything I'm doing is basically just feeding it data, where the data is sometimes a callable or class instance. So... I just make callables and class instances, kthxbye.

If you're making a library that uses a network connection, mocking that in your tests is crucial because you don't want to introduce the 500 extra variables of a network connection into your tests. You want to simulate the collection of variables you care about and test those. (Fake a 200 response, fake a timeout, etc.)

I am also, on the side, working on a simple photo gallery in Symfony 4. I'll be honest... it has no tests at all at the moment. That's because it's maybe 20 lines of code, plus templates, plus a bunch of external libraries. There's barely anything there to test, and I'm mostly just fiddling with it to see what happens at this point. At some point I'll probably put some functional tests around it, on principle, but at this point the fake image data I'd have to generate for it and the tooling to support it is not worth it. The libraries I'm using are all from Symfony and the PHP League, though, so I'm confident they're all very well tested. (Haven't hit a bug yet.)

As I've said elsewhere, best practices are contextual.