I have not tried to measure the performance impact, although I have no doubt that it exists and is significant. Basically it boils down to the difference in performance of doing memcmp() versus strcoll() for every comparison needed to sort your strings.
The bigger deal in my view is that it provides at least an option for a Postgres project controlled, built-in, immutable collation. Unlike glibc or ICU which are historically the only options (mostly glibc), and both of which are known to change their collation ordering from time to time completely outside control of the Postgres developers. If you want a deeper dive on why this is an issue, please watch the presentation I gave at pgcon last year found linked here: https://www.pgcon.org/events/pgcon_2023/schedule/session/345...
Built-in collation provider committed to PostgreSQL 17 (still in development) complements of Jeff Davis. This is a huge step forward for PostgreSQL users! If you don't understand why, you should research it.
The bigger deal in my view is that it provides at least an option for a Postgres project controlled, built-in, immutable collation. Unlike glibc or ICU which are historically the only options (mostly glibc), and both of which are known to change their collation ordering from time to time completely outside control of the Postgres developers. If you want a deeper dive on why this is an issue, please watch the presentation I gave at pgcon last year found linked here: https://www.pgcon.org/events/pgcon_2023/schedule/session/345...