In many ways, your point is correct and kind of difficult to argue against (i.e. I agree!).
What catches alot of people is they say how important types are but then just use 3 or 4 primitive types and never build custom types on top of them so they don't get much value out of those types aside from preventing the absolute worst runtime errors. The real value of types is having lots of them and evolving them over time as your systems and capabilities mature (US street address, US state, latitude, ... the list goes on for any piece of software).
I've had teammates "agree" and use types only to use the most basic possible types and then confuse themselves later (like, days later). But to me, because I like static typing, it comes very naturally to define types based on business logic, which makes things very easy to work with. And they're just not thinking in that way. Now I wonder how I can bring them around.
Edit: I wrote "but you should", I really should have worded that as "and you should". I am wanting to add to your point, not contradict it.
“Parse, don’t validate » is a common Googleable idiom
Perhaps you are thinking of this great blog post on the subject https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
I saw similar, catchy phrase: “parse, don’t validate”.
https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
Technically you can have more complex and custom validation (email is a valid email address) with annotations but the client-side will not have this information.
I guess that's similar to the redis example I gave, but it essentially means that even though we get sent JSON over the wire, we validate it fully and when it gets to our code we know it's a well formatted type. So our code can assume an email type is a valid email, an ID type is a valid ID, etc.