What maximum password length to choose when using bcrypt?

I don't favor silent truncation because it misleads the users into thinking that their entire password was accepted when it wasn't. I'd prefer a system just set a maximum length, if necessary, and restrict the user to that during password input. One bad scenario I've heard of is a code change that begins processing characters beyond the previous max length and suddenly the longer password users can't log in. The system only has a record of the first 72 characters and their longer string doesn't match that without the old system truncation. That leads to frustrated users.

As an alternative to truncation at 72 characters you should consider pre-hashing the password with something like SHA-256. The allows the user's entire password string beyond 72 characters to be considered while still providing the computational protection of bcrypt.

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.