If country is defined to be an ISO country, using the ISO two letter code, I do not think it is useful (the Locale does its job there quite good). But, we also have the need for further classifications, e.g. the ones defined by the Unicode standard (there called regions). Also here the Locale class may cover some of the aspects, since it is not only supporting ISO countries but also regions.
Nevertheless we also can argue for a even more flexible Region abstraction in our extensions module. We must ensure, that the Region model in our JSR is capable to model the aspects as defined in the Unicode standards (we also can relatively easily support such things in the RI, since the according XML data files can be freely downloaded).
Additionally when handling historic currencies and since currencies also have a relation to countries, then also a need for historic countries may arise, which then may not be covered the Locale class really. Hereby the problem seems to me very similar to namespaces and mappings for currencies. So perhaps we need to generalize these aspects and apply them similarly to countries/regions. Makes things not simpler, but at the end flexible enough to cover the complexity that is reality