The names on Unicode.Scalar.Properties directly reflect the UCD entry's name, without any attempt at choosing a better name other than basic grammatical transforms (e.g. the leading "is"). Swift is just directly echoing the data tables.
We should pick the best name for properties directly on Character, under Swift's interpretation of the result. These names may align, but if Character's name differs somewhat from the UCD's name that could be a benefit, as the behavior does not necessarily align directly.
Side note: I think isHexDigit is a totally reasonable alternative name to isHexadecimalDigit, as the "hex" short-hand has a pretty well established term-of-art status.
Future work: As for String.isASCII, we definitely will want to expose these kinds of queries in conjunction with work on performance flags, where the standard library will want to track known-ASCII-ness and other properties to enable processing fast paths. In that world, there's a isKnownASCII vs isASCII split, where that latter may require a scan of the entire String to compute. Or, this may be spelled String.isASCII(performScan: Bool = true), etc. Similarly for normalization status, trivial graphemes, perhaps encoding validity (if not enforced at creation), etc.