While you have a point, you shouldn't forget the Raspberry Pi. It is probably the most popular internet facing non-mobile ARM platform today. Literally millions of these run glibc and at least hundreds of thousands are in some way or form directly connected to the internet. While I don't believe that this bug can be exploited without first gaining RCE on the raspberry pi, once an attacker gets access to the rpi, this bug should be able to get them to escalate to root privileges.
There are quite a few people that put a full debian (or other) distribution on their NAS server. I own a zyxel NSA 325 and it is possible to install a full debian release on this and some other NAS boxes. These might be a limited amount of systems overall, but it's significant enough to deserve mentioning because they too often are internet facing.
Sendmail is historiy just as bind is history. Sendmail uses m4 for it's configuration files (you shouldn't edit the "compiled" stuff), so it's not sendmail that is culprit here. Bind is history because there's powerDNS now. Exim and samba aren't a mess, but they do use "text files" for configuration.
Anyway, they all use a standard, since it's human readable ascii. It may be obscure since there isn't much if anything that uses their format apart from themselves, but it's a standard. You could argue that all these apps should standardize on XML, but then you'd have all the tags that need to be standardized too. Going for binary files means humans will need extra software just to edit that and machine generating those will be harder too. The Windows Registry is a mess if I ever saw one and after about 20 years it's such a myriad of patches and additions that it's hardly managable.
Standards are great, which is why everyone invents at least one new one. Pushing very different requirements into one standard usually makes it either too crippled to be useful or too bloated to be maintainable. Maybe it's you that needs to find something else to do if you can't muster up the energy to deal with these inconveniances anymore. There will always be incompatibilities and annoyances if you have to deal with technology so either put up or move on.
Disclosure: I'm a professional Penetration Tester
We find plenty of this sort of setups at our customers. Customers set up VPNs, have a password policy and a virus scanner. They have firewalls and keep user policies restricted. Then we come and we trojan someone, or find a weak WiFi password or whatever we use to get a foothold inside their network all it takes is one little mistake and we're "in". Once we get there, we log keyboards, get password hashes from network or system memory and start to pivot all over the place. Usually, our software will trigger virus alerts, but staff doesn't react to those "in a timely fashion" and we get to keep going even though alarms are going off on several computers. We could cloak our malware and sometimes we do, but usually it's too much trouble and we get domain admin passwords within a few days and rule the network in such a way that admins wouldn't be able to get rid of us if we would rootkit and backdoor properly.
It takes more than some policies and a VPN these days. You need IDS, proper procedures, layered security and skilled, motivated staff that knows how to deal with security incidents. You need properly trained and aware users that aren't afraid to admit they messed up and that have no problem reporting others doing wrong either. Don't trust on a single technical measure, but implement them all and make sure you test and train on a regular basis. Get a data classification policy and protect data according to that policy. That means that stuff like SSNs and anything that can be used for identity theft should get extra layers of protection and alerting implemented. If you don't do all this, a serious intruder will usually get what they want.
Once you hire someone, they may want to leave because the atmosphere in the workplace isn't what they like, or the pay for their gender or ethnicity seems off compared to others. A large part of why some companies can't seem to get their "diversity" numbers anywhere near what they want them to be, is because they have a reputation that will put certain groups off whether deserved or not.
These are things that are much more important in the long run than just getting candidates in the door that have the right skills on their resume. That part is easy, just advertise and throw money at it. Keeping them and making them fit in the team is the hard part.
SD Cards can be several devices, including wifi cards, so those are just as (un)safe as USB devices if the device they are connected to would be susceptible to hot plugged hardware and have the drivers available for those.
SSL/TLS is plagued with bugs due to the backward compatibility issue. Heartbleed anyone?
Self Signed shouldn't be a problem, providing the device has the pubkey for the CA that was used to self sign present.
Doing a wget on an image requires at least a minimal install like busybox on top of a linux kernel. This is currently one of the most used ways to upgrade firmwares and often there are older version of busybox, the kernel and many other applications on the device. Those are one of the big sources of devices being hacked.
As you see, it's not as simple as it seems. Apart from standard apps being outdated and not validating certificates, a lot of the custom parts of firmware aren't written with any security in mind. Things like old fashioned buffer overflows, SQL/XML injections, XSS and whatnot in user interfaces are much more common than in directly web facing websites these days. With IPv6 around the corner and the end of NAT in sight, plenty of these devices will be connected directly to the internet and we will see a large increase in "things" getting hacked once we get to that point.
He probably is a smart guy, but these claims here would make me not want to hire him. He's so obviously full of himself that he'd probably never admit he might be wrong about something and that is just plain dangerous. So it's not just the hollywood drama, it's based on his on ludicrous claims.
This doesn't fix the underlying vulnerability; it merely scans for known ways to exploit it. I'm sure some clever people will find a way to thwart these scans and exploit the vulnerability, unless it gets fixed.
The only way this sort of thing can be taken care of is if Google or some governments in countries with a large market share will mandate vendors of phones or their manufacturers to provide security updates for devices for at least the duration of the contract, but preferably for the expected life of the device. Devices tend to keep working for three or four years, so that way Android users would get a similar security experience as iOS users.