Name representation in your DB may not match original. I think it even might be fine if you only allow ASCII to input names—most people who use a computer are probably used to writing their names in latin alphabet. But you should accept that the name you store is just an alias, a person identifier. And other points are valid: you can take into account others including #7, #37, #38, #18.
I think it's more about business process than technology limitations.
"I think it even might be fine if you only allow ASCII to input names—most people who use a computer are probably used to writing their names in latin alphabet."
But why? Why tell people they are second-class because of their alphabet preference?
Well, among Patrick's claims are that it's probably impossible to input all possible name even with all the power of Unicode, and that there are other limitations that prevent accurate representation of names in computer system, including human errors.
So my point is, maybe then it's better not to implicitly promise that your system has no limitations at all, but make these limitations more obvious instead. This'll help to avoid surprise errors and ensure consistent user experience by setting correct expectations.
I admit that most users today expect systems to accept their names in their language though, and that it might be an edge case depending on particular occasion, but then I can see why most payment systems apparently still accept only latin letters (cardholder's name is an example).
I think it's more about business process than technology limitations.