You can’t change primary keys, that’s the point, because you don’t know where they are.
For example if an old key is in a URL, and that URL is in a browser bookmark, now you need redirects, so you need to keep all the old keys around forever. Keys should be random or sequential, never contain information.
If you want to enforce uniqueness then use a unique index/constraint.
I think you are confused about the terminology because a primary key is a uniqueness constraint. They can be changed in any RDBMS worth its salt. Keys should not be random and your URL example is a case in point. The url /germany/berlin/2023/mcdonalds contains no surrogate key and is immensely more useful than the url /review?uuid=1kjksdhh3244ygdvvgdd2345.
A key is any set of unique columns. The primary in primary key just hints to the RDBMS how to store the data. Both URLs encode queries on the data. The first says "give me the 2023 review(s) of McDonald's in Berlin" (i.e., it has semantics) and the second "give me the row with uuid 1kjksdhh3244ygdvvgdd2345". I don't think the second URL is more robust because, for example, if the row has to be recreated it will fail to work.
For example if an old key is in a URL, and that URL is in a browser bookmark, now you need redirects, so you need to keep all the old keys around forever. Keys should be random or sequential, never contain information.
If you want to enforce uniqueness then use a unique index/constraint.