I wonder if there is a real cause and effect relationship between being good at this kind of games and being a good coder. I suspect not.
A lot of people are good software engineers and can wrote good software. To get Jeff Deans that write revolutionary software, we don't yet have a better method than training people in these abstract, very hard problems, making them compete and hoping for the best.
As much as we software engineers / computer scientists believe we are special snowflakes, this exact same method is applied to most STEM PhD to professor tracks, mathematics, classic music instrument players, [athletes], and what have you.
[post] https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n...
[athletes] http://rittersp.com/wp-content/uploads/2014/03/Chambliss-Mun...
[musicians] http://www.nytimes.com/images/blogs/freakonomics/pdf/Deliber...
This is of course a different question than whether this test provides maximum predictiveness of future success. But it seems obvious to me that the test provides some information. It's really hard for a variable to be completely non-informative.
Lastly, I think it's important for us to not be too defensive. I sense, perhaps incorrectly, that sometimes we don't want to give value to tests we are bad at, because doing so would imply we aren't as good as feel we are.
Or to put it more pessimistically: even worse than we feel we are. Impostor syndrome and all that.
I've been playing these games for a couple of years (initially, for interviews preparation), and it's been very instructive. The competition format makes it convenient and addictive. There's no doubt that I improved a lot on algorithms, data structures and on "small scale" coding. While this is useful, it is quite different than what you do when working on real projects.
So there's a couple of advantages if you can execute code in your head line by line while storing state as well. You can be slightly faster and more correct while coding yourself and while reviewing the code that others have written. Typically in the latter case you don't have the benefit of the compiler or running tests.
In my anecdotal experience I found an improvement in my "head interpreter" after practising interview questions for a while because typically you're not allowed to execute your code. I can't say if any of the algorithms I learnt and practised helped, but this, in my opinion, made me slightly better at my day job.
Puzzles are fun, but it's best not to put too much predictive faith in them, because otherwise you're just affirming the consequent. Exceptional individuals are quite likely to be good at puzzles, but you cannot (in my experience) assume that because someone is good at puzzles, they have actual skill in solving real-world problems. I've worked with too many counterexamples.
I don't even bother replying to their recruiters any more. The interview process tells me more than enough about the company.
The part where you make large software, working in teams, to serve real users, can only be learnt on a job.
These competitions are not looking for anything fancy. They recruit juniors, they'll be trained on the job.