Whilst I don't totally disagree with many of the points here, I think there's a wider picture to many of these issues.
The author is concerned with installing packages on user machines: which are typically very long-lived installs - maybe a user has the same machine with the same dependencies for years.
However, for many engineers, (such as myself), a binary may not be used past even a few days from when it was first compiled - e.g. as part of a service in a a quickly continuously integrated system.
I might even argue that _most_ software is used in this way.
When software is built this way, many of the points in this article are very helpful to keep builds stable and to make deployment fast - and in fact for the case of security, we usually _don't_ want dependencies to auto-update, as we do not want to automatically deploy new code if it has not been audited.
Maybe there's a future were OSs become more like this, where binaries are more short lived... maybe not. Although I don't think it's strictly fair to label all of these as "Bad" with a capital B :)
"if you need a tool, buy the cheapest one you can find. If it’s inadequate, or breaks, or you use it a lot, then buy the best one you can afford"
I don't know how I feel about this... The unsaid thing here is that you will end up landfilling the broken or inadequate tool and buy twice what you need.
These days, if I'm going to put money into buying material goods, I feel they have to meet at least a minimal "this isn't going to end up in landfill after the first time I use it" bar.
A lot of cheap tools barely meet this level, sadly...
I think a common conflation is seeing "making something future proof" as "making it more generic".
IMO, good future-proof design is about putting in place good components and system boundaries.
Those components and boundaries can be highly specialised and have as few options as possible - it's much easier to make a system boundary more complex than to make it simpler. So start as simple as possible!
Now, with those boundaries, you can easily write tests, and iterate on the different parts of the system. Bad code in one component doesn't "infect" bad code in another part of the system.
Most "balls of mess" systems that I have seen came down to not having clear boundaries between components of the system, rather than being too generic or not generic enough.
You can use custom domains with SSL
Here's a full example:
https://github.com/rosshemsley/rosshemsley.co.uk