Then there's the element of surprise. If, for example, I was developing an FPGA-based board for a drone or a medical device, I would, more than likely, require that 100% of the design be done in house (or crazy extensive testing be done to outside modules).
Anyone in software has had the experience of using some open-source module to save time only to end-up paying for it dearly when something doesn't work correctly and help isn't forthcoming. If the software you are working on is for a life support device it is very likely that taking this approach is actually prohibited, and for good reason.
While I fully understand your point of view, this is one that reduces software and hardware development to simply wiring together a bunch of includes. In my experience this isn't even reality in the most trivial of non-trivial real-world projects.
FPGA's are not software.
I see these "FPGA's for the masses" articles pop-up every so often. Here's what's interesting to me. If you are an engineer schooled in digital circuit design, developing with FPGA's is a piece of cake. There's nothing difficult about it at all, particularly when compared to the old days of wire-wrapping prototypes out of discrete chips. Sure, there can be a bit of tedium and repetition here and there. At the same time, one person can be fully responsible for a ten million logic element design...which was impossible just a couple of decades ago.
If you don't understand logic circuits, FPGA's are voodoo. Guess what? A carburetor is voodoo too if you don't understand it.
Let's invert the roles: Ask a seasoned FPGA engineer without (or with superficial) web coding experience to code a website --server and client side-- using JS, JQuery, HTML5, CSS3, PHP, Zend and MySQL. Right.
Then let's write an article about how difficult web programming is and how it ought to be available to the masses. Then let's further suggest that you can do nearly everything in web development via freely available includes.
I happen to be equally at home with hardware and software (web, embedded, system, whatever) and I can't see that scenario (development-by-includes) playing out in any of these domains.