Adding __slots__ is reasonable.

Adding caching to fold together repeated addresses is dubious (it comes with its own space and time cost but won't benefit all users) and, as David said, the decision on how to handle this is up to the user.  Also, it is rather late in the game to be challenging the design of the module.  IIRC, this code or some variant of it already had heavy use prior to landing in the standard library (it also took into account what was learned with various other ipaddr modules).  The module docs say that the library was designed for speed and makes no mention of optimizing for space.

For the most part, once an API is deployed, users can be expected to exercise every feature whether intended or not.  Right now, you can add attributes to two otherwise indistinct ipaddresses.  The OP proposes to break that code.   Right now, if a user has concerns about memory use due to duplicate address instances, they can easily created their own interning scheme (a = intern_dict.setdefault(a, a)).  If the OP get his wish, then those users will be worse off (due to double interning).

In other words, this ship has already sailed.