The general purpose of checksums is to allow errors in transcription to be detected by means of a simple algorithm applied to the number itself, and without access to any other information (such as access to central records).
Error-detection methods require a certain amount of redundancy in the data, and there is generally a desire to economise on the amount of redundancy, because handling additional data increases the clerical workload, and increases the very risk of transcription errors whose occurrence you are trying to detect and prevent. You wouldn't want to double the number of digits, for example, as the price of including a checksum.
Therefore, most checksums are tailored to detecting certain kinds of the most common transcription errors whilst introducing the smallest possible amount of redundancy into the data.
If I remember correctly, the most common transcription error is getting a single digit in a single position wrong, followed in second place by the swapping of two adjacent digits (i.e. getting two digits in two positions wrong, but in a specific pattern).
Many trivial algorithms can detect the first kind of error - the change of one digit in one place. The most trivial is just adding up all the digits - hence the name, "checksum".
But the algorithm you describe is specifically designed to detect the second kind of error as well as the first, and without introducing any extra checksum digits.
The general tradeoff with complicated algorithms is that more-commonly-encountered kinds of error are detected, at the expense of the algorithm detecting fewer more-rarely-encourered kinds of error. But more complicated algorithms therefore detect more errors overall, because they are better at detecting the errors that clerks frequently make, and the errors they cannot detect are errors of the kind that clerks rarely make anyway.
A particular feature of the algorithm you describe is that when applied to any possible input number, it produces a result between 0 and 10 for the checksum, the last of which requires two digits to represent (in decimal numbers, which run 0-9).
Since it is undesirable to introduce additional digits, and because the designers probably didn't want to introduce an alphanumeric aspect (such as how hexadecimal numbers are represented by 0-9 then A-F, or how the ISBN checksum scheme represents 10 using the letter 'X', which corresponds to the Roman numeral for 10), they simply don't allocate base numbers which cause a checksum of 10.
Because no valid base number then has a checksum of 10, any calculated checksum of 10 always indicates a transcription error.
As to why they chose to disallow a checksum of 10 specifically (when they could have chosen any in the range 1 to 11), I cannot say offhand, but there is almost certainly some additional statistical or computational rationale, that either makes the algorithm more straightforward to apply (by hand or by computer), or which maximises the overall number of transcription errors detected.