I am usually the person who argues against silly limits but I have to wonder: who seriously uses passwords of over 72 characters? Such a long password would be very impractical to type so it's almost certainly a robot (or ctrl+v from a password manager). Robots* and password managers don't care if they have to remember random alphanumeric strings rather than passphrases.
Assuming they don't use special characters, that is 26+26+10=62 possibilities per character and let's say up to 72 characters. This allows for
62^72 = 1.13*10^129 possibilities. Converting to bits of entropy, a much more manageable number, we get
log(62^72)/log(2) = 428.7 bits of entropy.
Last I checked, 256-bit keys are considered reasonable even post-quantum, so this should be plenty.
In the rare event that it is a passphrase, let's take a very standard dictionary: the default one on my Debian system. After some standard pruning (case-insensitivity; removing possessive variants like "horse's" instead of "horse") it contains about 50k words. This math I'm less sure about, but I think this means each word, when randomly picked (as you should with passphrases), gives about
log(50000)/log(2)=15.6 bits of entropy. Average word length in general is considered 5 characters, plus a space, so 72 is about 12 words.
This comes down to
15.6*12 = 187.3 bits of entropy in a 72-character passphrase. As a lower bound, because my dict does not contain all words. I'd say you're good.
The real silly limit is bcrypt's 72 characters, but if that's what you've got to work with, I think it's a reasonable limit to set for the users.
* OK, fine, maybe robots would care. Ask me again when the Robot Rights Amendment is there.
Edit: I was answering the title. To address further questions in your post:
So the question is, is it better to just set the password length limit to 72 characters or let users choose longer passwords [...] even though they will be truncated?
Don't silently truncate. There is no advantage in this. Either you will get support requests "boo-hoo I can't use a 105-character password" or eventually someone figures out "OMG I only have to enter the first 56% of my password for it to work what is this crap?!?!?". I think the latter actually has a reasonable point and the former will be extremely rare (if ever).
The first criterion is security and only then usability
I think you might be interested to learn about client side TLS certificates.