Just knowing how to write a binary tree, or linked list, or singleton, or whatever, doesn't make one capable of writing a program that users want to use. Yes, maybe it makes one capable of writing a perfect program even, in the sense that it may even be mathematically proven correct; yet that's absolutely irrelevant outside of the realm of the theoretical. The basics of this nature are well-documented everywhere already, and it's not necessary to know all of them before doing more integrated exercises; full applications that people actually want to use.
You state that theory is diverged from practice, which in general is one of the most rotten notions people commonly hold, but the very same sentence seems to indicate that you don't really understand the theory you're talking about - you first equate Computer Science to mathematical proofs of correctness, then you imply that proofs of correctness are useless in practice, both statements being equally unwise. Your users still want to use fast software, solve hard problems, do not like to find bugs in your programs and your colleagues still would prefer that the code you are writing is easy to understand and easy to maintain. It is not possible to go long-term about solving hard problems (writing fast programs being one of them) without knowing or inventing the necessary theory, and without lots of experimenting as well, for which there is ample historical evidence in the history of science and engineering.
I don't care if you do book exercises, katas from the web, or invent your own toy project, but you have to practice writing programs, including small programs, involving some actual domain problems (theory!) to be a really good programmer. A few times when doing recruitment for my company I asked the candidates to prepare a small program for me, first time a program extracting links from a given url, the other time a small TCP chat server and client. Such a program can be elegantly written in a page or two of code, yet 90% of people can not write a bug-free program of this kind at all, not to mention achieving elegance (ease of understanding the code + good maintainability + good performance). They of course won't cope well with a larger program and/or larger problem, they are just used to patch things together in a chaotic way until they find a combination that works. This tactic doesn't scale well to hard problems unfortunately.
The only reasonable function of the analogy to Karate is that calling an exercise a "Kata" might be motivating for some people and sounds nice. Carrying it any further doesn't have any meaning. For one, 90% of the time you spend doing Karate is doing various kind of exercises and you get in a "real fight" a few times in a lifetime perhaps. No wonder martial arts that spend those 90% of the time on something more related to the situation you want to be prepared for actually get you better prepared for the situation. I also doubt the goal of Karate is beating people up in the street or in some fancy cage. In programming the exercises are just an addition to performing your real work, which is probably done almost every day anyway.
You need to practice more in making your ad hominems more subtle and try to provide at least some actual reasoning for the things you claim, and if you're going to call people stupid you can at least try to do so by referring to things they actually said.
Anyway, what your users want is a program that they can figure out how to use, and one that they actually can get on their computer, and that does the things they need them for - all of which have absolutely nothing to do with whether you used a quick sort or a bubble sort. Being fast, solving "hard problems" (methinks you're a bit full of yourself - when was the last time you heard someone say 'man, if only I had software that would solve a hard problem'?), and being maintainable are all secondary to the actual use - i.e. having a user interface they can understand, provide output in terms they understand, etc.
In your second paragraph you are actually making my point for me, but you don't seem to realize. What users want is a program that does something for them, like extracting links - and they don't care if those links are stored in a linked list or array. Maybe in some cases they will care at some point in the future that, when they download 10's of thousands of links, that happens a few seconds faster in some cases than in others, but that's not their main concern.
You state that theory is diverged from practice, which in general is one of the most rotten notions people commonly hold, but the very same sentence seems to indicate that you don't really understand the theory you're talking about - you first equate Computer Science to mathematical proofs of correctness, then you imply that proofs of correctness are useless in practice, both statements being equally unwise. Your users still want to use fast software, solve hard problems, do not like to find bugs in your programs and your colleagues still would prefer that the code you are writing is easy to understand and easy to maintain. It is not possible to go long-term about solving hard problems (writing fast programs being one of them) without knowing or inventing the necessary theory, and without lots of experimenting as well, for which there is ample historical evidence in the history of science and engineering.
I don't care if you do book exercises, katas from the web, or invent your own toy project, but you have to practice writing programs, including small programs, involving some actual domain problems (theory!) to be a really good programmer. A few times when doing recruitment for my company I asked the candidates to prepare a small program for me, first time a program extracting links from a given url, the other time a small TCP chat server and client. Such a program can be elegantly written in a page or two of code, yet 90% of people can not write a bug-free program of this kind at all, not to mention achieving elegance (ease of understanding the code + good maintainability + good performance). They of course won't cope well with a larger program and/or larger problem, they are just used to patch things together in a chaotic way until they find a combination that works. This tactic doesn't scale well to hard problems unfortunately.
The only reasonable function of the analogy to Karate is that calling an exercise a "Kata" might be motivating for some people and sounds nice. Carrying it any further doesn't have any meaning. For one, 90% of the time you spend doing Karate is doing various kind of exercises and you get in a "real fight" a few times in a lifetime perhaps. No wonder martial arts that spend those 90% of the time on something more related to the situation you want to be prepared for actually get you better prepared for the situation. I also doubt the goal of Karate is beating people up in the street or in some fancy cage. In programming the exercises are just an addition to performing your real work, which is probably done almost every day anyway.