I see where you're coming from, and looking at the problem from a purely technical perspective, I agree with you. A password is just a string of codepoints. Accept what you get, yeet it into a password hashing function, and be done with it.

However, in my opinion, for real-world systems, you need to strike a balance between technical and operational, and user experience concerns. If restricting your password space to printable ASCII characters can meaningfully decrease the amount of the tickets that generate half of your ticket volume, you should give it some serious thought.

There are good arguments for both approaches, and the right way also depends on your user base. There was a story about WhatsApp a while ago, criticizing that WhatsApp would only notify users when their contacts' security code had changed, whereas Signal (and other secure messengers) would block and ask for confirmation first. Signal currently sits at 100M+ downloads in Play store, WhatsApp sits at 5B+. The numbers are very vague, but WA has 1-2 orders of magnitude more users than Signal.

In the WhatsApp example, a small change in the process can mean that good security becomes accessible to a pool of billions of users, vs. excellent security to millions. Restricting the password character set (to a sensible set of characters, and with a sensible length limit) comes with no security drawbacks, and good chances of some process/usability improvements. For a real-world deployment, I would argue it's very prudent.