People were arguing for such a thing because e.g
if you have 2 guids then you can write code which handles two completely unrelated guids
like
`student.Id == car.Id`
meanwhile if you have types like StudentId and CarId then you'd have compilation error
While I'm not a fan of this, then the concept is sound.
For value objects, surely Leibniz's philosophy applies: if a theory describes two situations as being distinct, and yet also implies that there is no conceivable way, empirically, to tell them apart, then that theory contains some superfluous and arbitrary elements that ought to be removed.
For entities, it's much more complex.
I still feel some kind of way when seeing classes (with methods!) being used for IDs, though.
Depends on the language. In many languages strings are classes in general, so it makes sense that a new type for a strong is is one as well
Modeling the business domain with types that match it is table stakes. Otherwise you end up with a "stringly-typed" codebase in which everything is just a primitive type.
This and the issues the author of the article is facing comes from the wrong mindset. Your job is not to create the purest, most perfect codebase, but to deliver value to your users. Code is a means to an end.
This. Before you wax all philosophical, try to understand first what you are arguing for and against. Make sure to read what you wrote at least two times, and that it actually makes any sense.