I think I'm just not creative enough to think of features that need to be implemented by the language and not easily done at a library level. You could prevent the access to secret's contents by creating the appropriate class, but I suppose it would be harder or impossible to allow the user to peak into the contents but disallowing using them for branching specifically. Though, I'm not sure where that can be useful in practice. Also, I'm not sure how that language feature can mitigate meltdown and spectre. How can it do that?
I'm no expert here, but the arguments I can think of a couple possible arguments. One is that it's not always possible for libraries to ensure that programmers use them correctly. This may be particularly true for systems programming languages that often permit low-level features such as pointers. The second is that the compiler can do things that a library can't.
Spectre/Meltdown mitigation is a great example of the latter. The compiler can be careful to emit instructions that don't permit speculative branching, or disable other optimizations that might expose a security risk. Libraries don't typically get the kind of access that would permit them to do that, and it's not clear to me that a language that does permit such access would be appropriate for safety- or security-critical applications.
As for why if statements are a security risk, they give a tidy little example of that at the bottom of their overview page, under the heading, "Can you see the security flaw in this code?" I can't say I understand it terribly well. I personally take that as a sign that, while I can speculate about why they're doing things this way, and even be arrogant enough to do so in public on the Internet, I'm very, very, very far from being qualified to suggest that their basic approach is wrong. Chesterton's Fence sometimes strikes me as being overblown, but Chesterton's Safety Belt is no joke.
