The source you cite actually already points out the problems, although it does actually considers these as problems but as advantage. To cite:
Pros and Cons
The highlights of this solution are:
5. Faster to compute - verification is several multiplications of 32 bit numbers that is much much faster than computing a hash value.
The attack you are trying to prevent is that the attacker can guess correctly provided that the attacker knows the secret information stored in the database.
In your example you have a secret with 10 alphanumeric characters where the attacker needs to guess a specific 3 characters. This means 363 guesses are needed when only upper-case characters are allowed or 723 with also lower-case characters. Given that the check is very very fast the attacker can quickly find out these values (i.e. likely real-time) if the secret stored in the database is known.
If the attacker must choose more than 3 characters it gets harder to do in real-time but it can be easily precomputed. If 5 out of 10 characters are needed than 10*9*8*7*6/(2*3*4*5) possible "masks" for entering the characters must be precomputed with each has at most 365 (or 725) possible values, i.e. at most 10*9*8*7*6/(5*4*3*2)*725 really fast computations must be done. Assuming that 10000 computations could be done in a second this would take the attacker a day if he has a botnet of about 600 machines - which is not unreasonable. And it could probably be optimized. With 4 out of 10 characters one would only need 6 machines for a day and with 3 out of 10 a single machine could do this in less than 1.5 hours.
Note that this estimates also assume a random secret. If it is a user chosen secret it gets much worse since the search space is smaller. But, if the user can not chose the secret then he probably needs to write the random secret somewhere - defeating your original idea why this additional secret should be given (i.e. prevent shoulder surfing and storing in password managers) in many cases.