If you're worried about compromised CPUs being used to compile executables that are used by others, then reproduceable builds are a great countermeasure. Just use reproduceable builds on many different CPUs, and compare them to ensure they are the same (for a given version of source and tools). The more variations, the less likely that there is a subversion. If what you're compiling is itself a compiler, then use diverse double-compiling (DDC) on many CPUs.
If you're worried that an INDIVIDUAL may end up with a compromised CPU, then yes, it's much harder to counter attack. On some systems, you can isolate the system (no network traffic, etc.). That said, an adversary has to send packets to subvert a specific system, then every time they do the subversion they risk being detected, so it's far less likely to be used for bulk surveillance... it would more likely be one well-resourced organization (e.g., a government) working against another well-resourced organization.
If scholar just means "one who studies", then obviously anyone who studies a religious text for a long time BECAUSE they're a believer is by definition a scholar. I don't think that's what you mean.
If we change "scholar" to "scientist", it's quite clear that scientist is not synonymous with atheist. Pew research found that "just over half of scientists (51%) believe in some form of deity or higher power; specifically, 33% of scientists say they believe in God, while 18% believe in a universal spirit or higher power". Besides, many would say that science requires repeatable experiments, and many truths simply aren't repeatable (e.g., history).
Most scholars don't think that the Talpiot Tomb has anything to do with Jesus. For exampel, Géza Vermes says the arguments for the Talpiot tomb are not "just unconvincing but insignificant" (see the Wikipedia page). Also, Christian theology does not depend on whether or not the shroud of Turin is real.
I'm not muslim, but even the summary notes a perfectly reasonable explanation - the parchment could be an old one. And frankly, I'm skeptical that the carbon dating is that precise; carbon dating depends on a lot of assumptions that can easily be false in specific circumstances. (Yes, radioactivity decreases at a fixed rate... but you have to make BIG assumptions about its starting value.) So while this article makes for a good headline, the current actual evidence is rather worthless.
What about the disastrous SwiftKey vulnerability? It makes Samsung Android systems vulnerable too. Samsung said they'd fix it back in June, but we still have no patch.
When buying an Android phone: Measure how many days it takes from the vulnerability report (at least publicly) until it's patched in phones already used by customers. Focus on phones more than 2 years old, since your phone will be that age someday. Then: Don't buy from unresponsive makers. I suspect that if a few buying guides included those numbers, some manufacturers and service providers would start paying attention.
"How would an experienced developer get these problems in the first place?"
A lot of projects do not follow widely-accepted best practices... even if they are experienced... and that is a problem!
A remarkable number of OSS projects fail to have a public source control system (#2). That includes many established projects that everyone depends on. Actually, a number of OSS projects - and projects that people THINK are OSS but are not (because they have no license) - fail many of these points. It's not that Red Hat's internal processes are immature; Tom was trying to bring in software from someone else (Google in this case) and was fed up by the poor practices from people who should know better.
Yes, #7 refers to a best practice (let people pick their install directory) that's been around for at least 20 years and probably much longer, but it's still widely NOT followed.
Anyway, that's Tom's point; there are a lot of widely-accepted best practices that are NOT followed, and that needs to change.
All power corrupts, but we need electricity.