Conversely, I often need to log or store API-provided entity ids on my side, and having to parse it out of a URL or store irrelevant URL bytes in my own database would be really annoying.
You're not going to avoid the need to compile entity URLs on the client side either, unless you only make requests to entities returned by the API, which would be a weird constraint to design client code around.
I really don't see the point to any of this.
The validation would be intrinsic in the client side concatenation of the server address with the relative URI.
For example, the article includes URLs like "/people/123". The security of having a leading slash in these depends on API base URL.
"https://api.hotstartup.com/v1" – safe
"https://api.hotstartup.com" – unsafe with ".evil.com/people/123"
I wouldn't really call this particular scenario a security issue, but allowing such things is a bad habit that will eventually bite. It's like not HTML-encoding values like usernames that you "know" are safe (but you know are not HTML-encoded).
If I visit an HTML page with a link to “.evil.com/people/123” and click on it, the user agent won’t append “.evil.com” to the hostname. You’d instead get something like “https://api.hotstartup.com/.evil.com/people/123” which would be safe (if not broken).
If all you stored was the ID, all you would need to change is the logic in your API client which accepts the ID and constructs the URL for it.
For example, if the entity ID changes from being an integer, to being a GUID, you'd still have to write code to update your schema (presumably, from an int column to a GUID/string column).
I also mentioned that I don't want to store redundant garbage in my logs and database, especially if I want to index the column containing that entity id.