Is there ever a reasonable case for a "natural ID" like we were taught in database school? In my working experience, I always use either an autoincrementing integer or a random string / uuid as the primary key.
Not even then (at least not great). Companies change domains, primaries become aliases etc..
Most natural keys that identify dimensions of your data are slowly changing anyway - an address isn't a permanent fixture of a building, an area code splits, nations go to war, daylight savings changes on a whim, laws change, rules change, our understanding of the universe changes.
1. Built-in Deduplication. If your ID describes the "thing that it is" handling deduplication is much easier. Of course you can try to enforce it by enforcing uniqueness on other columns (but that's not always possible / can get tricky).
2. Save a DB trip on updates/some creations / make indexing more explicit. E.g. say you are user with email address and you want to update some info. Either you run an update using the email directly (in which case you are treating it as a PK essentially even if you don't call it that) or you first retrieve the relevant PK by whatever logic (say indexing by email and name or whatever) at which point you do have an implicit natural key.
In my experience every time I have seen a "corporate" DB with non natural key you get a LOT of duplication and all sorts of services to try to resolve entities running in a batch way (the horror..).
And 2 leads to a lot of bugs because of the implicit nature where you accidentally update the wrong or multiple rows because you didn't know what the implicit uniqueness "key" entailed.
2) Usually, the update does not happen in the blue. It's often done after a load operation, for optimistic locking. In that case, the PK is available for free.