First, I think that there's a distinction between constructive, humble criticism, of the form "Why can't the CPU be designed in such a way that ___", and statements like "Well, a competent CPU designer would have done ___". That distinction is not just politeness (although politeness is of intrinsic worth); that decision leads to better technical outcomes. There might be a good answer, like "It can't be designed like that because of the following constraints" or "We tried it and couldn't get it to work"; there might just be an answer like "That's totally the right thing to do and we just cut corners" or "We never thought of it but our competitor does that and it seems to work for them, yeah." Unlike arguments about how competent people actually are, these discussions contain actual technical content, and help different people understand each other's points of view (which is the whole point of having an online, public, decentralized development community, is it not?).
Second, yes, I think that we should discount, though not by much, criticism from people who say "I could totally do that in a better way" and have not actually tried to do that (or have tried and failed to launch a product). There's a lot of things about building complex systems (like modern CPUs) that aren't apparent on paper, and only become apparent once you try to reach some challenging level of scale or performance. This is not at all to say that there's no place for outside criticism; often outside criticism can offer fresh perspectives, or suggest a way to simplify the system and avoid the emergent problems of complexity. And often there are people who are genuinely qualified and really could build a better system, but happen to be working on something else. But it's still fundamentally outside criticism. The only people who can really say "Yes, you totally could have done this instead" are those who actually did.
Third, in this particular scenario, it happens to be the case that ex-Intel employees with insider knowledge have called out Intel for cutting corners (see the "Update" section of https://danluu.com/cpu-bugs/), which seems like a much more productive basis to have a technical conversation.
And if those stories are to be believed and if they're relevant to this problem, the problem is not the competence of engineers - the problem is the competence (or the confused incentives, really) of management who are not telling their engineers to invest time into doing things the engineers know perfectly well how to do, or are telling their engineers to invest time into building other features that make those things harder. (For instance, quite possibly some part of management got worried about benchmarks of syscall performance and told their engineers to prioritize that over making sure that there aren't side-channel leaks between rings.)
