Do you mean my advice to not reinvent the wheel and use an existing plugin that solves a problem? If so, let me preface that advice by saying, “depending on your goal or situation.”
For instance, if you’re a freelance developer and running a one-person agency using WordPress to generate (or enhance existing WP) sites for clients, you’re going to want to take advantage of the existing solutions to already solved problems, so you don’t have to write custom code from scratch every time.
In that particular scenario (agency-of-one), you are likely to build out your own custom theme (or become very familiar with a popular, well supported, highly-customizable existing one) so you know the ins-and-outs of it. You are also going to get to know the better plugins/blocks/templates out there for common things. Eventually, you’ll grow a list of your favorites (likely even creating a few of your own along the way for custom stuff where there isn’t already a usable solution).
If, on the other hand, your goal is to just create something for the sake of learning it or for a scenario where you think you can implement a better solution (or fill the needs of a market/problem where there is a gap) and you have the time to do so, then absolutely you should roll your own solution.
I wouldn’t call that common knowledge. I’d say that is a common misconception. There are WP sites using many plugins with good performance. Number of plugins isn’t always an indicator of bad performance. Quality of plugins used is certainly a factor, but number of plugins? Not as much as you’d think. Join some WP Performance groups if you’re interested in that, or if you don’t want to take my word for it, and ask around.
If you’re using a good plugin you can hook into it and tailor it to your needs. If you’re using a great plugin (open source plugin that is) you can contribute back things that make the plugin better for everyone. And if a plugin isn’t doing something properly, you should not be using that plugin.
Easier for who?
Easier for you, maybe. Easier for the person who has to maintain it after you? Answers to either probably depends on how much time goes by between building it and having to dig into it again to patch or enhance it. How well was it documented? How well was it built for maintainability/extensibility? How testable? Etc.
All the code for any themes/plugin you use is available to you—if you need to know what it’s doing you read the code. If you’re concerned about WP being a black box, it isn’t. The code is there to read—if you need to, but you often don’t because—it also has good supporting documentation of it’s inner workings.
Yes, certainly… but our job as developer is not just writing code all of the time. Reading existing code is a hugely important skill. Debugging existing code is a hugely important skill. Enhancing existing code is a hugely important skill. You will not always have the luxury of greenfield development (where you are starting from scratch and making all the decisions), you’ll eventually have to deal with brownfield development. You will be a more versatile developer if you are as comfortable on a greenfield project as you are on a brownfield one.
My advice was because you need to work with an already existing WordPress site. You don’t have to go with a n existing block or plugin if you really want to build something on your own. You can create your own page template/block/plugin, if you want to write it all from the ground up. You still have to play in the WordPress sandbox though (meaning, in it’s way of doing things). And if you do build it yourself, do let your client know what the options are for support and maintenance.
To wrap up, you’re not completely mistaken. It was a good question. Like most things, the answer depends upon the details of the individual scenario.