When I generated password for GitHub with KeePass I got a message on GitHub site that said the limit for password length is 72 characters. It seemed weird it not being a power of 2 so I googled a bit and it appeared that 72 is the max bytes for brypt algorithm. So it seems logical to restrict the number to 72 as longer passwords would be truncated to 72 anyway.

Then I generated password for Discord and it appeared that the max length is 128 characters. But I thought that I'll check if the first 72 characters from my password would suffice. And yes, my 128 character password is also truncated to 72 first ones, so I guess Discord is also using bcrypt.

So the question is, is it better to just set the password length limit to 72 characters or let users choose longer passwords (how long? 128, 256 bytes?) even though they will be truncated?

The first criterion is security and only then usability, storage or difficulty of implementation.

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 salted SHA-256.  The allows the user's entire password string beyond 72 characters to be considered while still providing the computational protection of bcrypt.  Please read the linked question and comments below to understand some of the security tradeoffs of this approach.
