What makes that different from creating a Secret class that's just a container class and defines its own methods? I just don't see what it is that requires a new language to accomplish and couldn't just be implemented as a library in many of the pre-existing languages (including popular ones like C++).
It seems like we're focusing way too much on just the very first example, instead of the feature list as a whole?
There are plenty of other interesting features, such as disallowing conditional branching on the contents of secrets, all the way down to enforcing Spectre and Meltdown mitigations around secrets without necessarily globally taking that performance hit on sensitive and non-sensitive data alike.
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.
I implemented it as a runtime class in Python just to see, seems like you can get a lot of (this benefit) in other languages by doing the same: https://github.com/yasyf/python-secret-type