This is part of the reason why I prefer structural types (like in Typescript, Go and OCaml) over nominal types (like in most languages), as any object with the required methods is automatically an instance of such a type, instead of having to explicitly declare that it "is"/"extends"/"implements" that type.
I suspect that with dependent types, nominal types are actually a degenerate type of dependent structural type: a dependent pair of a type and a proof that a string 'name' field has some particular value, or that a list<string> 'implements' field contains some particular string (the interface name).
It's also really good for testing: if you want to mock some opaque third-party object, you can just create an interface with the same methods as that object and use it in your code. Nominal types often don't allow this, such as how in Java you can't make a class to which you don't have the source implement your own interface, or make it painful, like orphan instance restrictions in Rust and Haskell.
I suspect that with dependent types, nominal types are actually a degenerate type of dependent structural type: a dependent pair of a type and a proof that a string 'name' field has some particular value, or that a list<string> 'implements' field contains some particular string (the interface name).