"Word" has never been an unambiguous term, which is one reason why we don't normally use it in the library or in documentation.
Pointer size is also a surprisingly complex concept: in addition to targets like arm64_32 or x32 with artificially restricted address spaces, there are interesting targets (such as GPUs) with non-unified address spaces, as well as various proposals to use fat pointers for security hardening (which can mean that the range of pointers can be substantially smaller than their storage size).
Regardless, Swift makes an assumption in several places that the target has an acceptable generic address space which class references, UnsafePointers, etc. must fall within. That choice of address space is a core and immutable aspect of the definition of the target, and if we wanted to support e.g. wide pointers on arm64_32 then we would need to provide new language mechanisms to access that wider range.
I have always considered Int to be tied to the range of that generic address space, and I am fairly certain that the library team agrees, and that is reflected throughout Swift's API. I don't know if we've ever said anything about that officially, but if we haven't, I'd be happy to run that statement past the rest of the Core Team, and I don't think we'd hesitate about it. Given that, I don't think we should provide redundant ways to query the range of Int vs. pointer size.