To add to that … in a traditional Linux multi-user environment, after you log in, you will get the keyboard for the locale that the logged in user has selected (or indeed the keyboard that the logged in user has selected when it is possible to customise that choice). Clearly, that is not possible during disk decryption - since you can’t possibly yet be logged in.
There has to be a keyboard built-in to the boot environment that is used to handle disk decryption - and by definition that keyboard is being used before the root file system is even mounted.
I dare say that it would be possible to customise the keyboard used during boot. However if you get that wrong then you will likely completely lock yourself out of your phone and you would need to use Jumpdrive to reverse that customisation. You may also find that a system upgrade overwrites your customisation unless the boot environment caters for that customisation (I haven’t checked) and that again could result in losing access to your phone.
At the end of the day, you have to weigh up the benefits of using unusual characters in a LUKS password (stronger password for a given length) against the risks that have been outlined in this topic. It is your phone.
However, if it were me and I had made the decision to use an unusual LUKS password then the bare minimum is to know how to recover access to your phone if things go pear-shaped.
(In an ideal world?, the Disks mechanism that allows you to change the LUKS password would use a non-standard keyboard i.e. use the built-in boot keyboard rather than the user-selected keyboard - so as to make it harder to enter a LUKS password that will then lock you out. However I don’t know how easy that would be to implement.)