First, I think the paper is a fantastic summary.
Second, the encoding list in the Google Sheet may contain some false positives. As a Chinese, I noticed the weird GBGBK immediately. I have no idea what it is, and googling does not reveal interesting results, and GBGBK does not exist on macOS (Sequoia) or Ubuntu (24.04 LTS). Claude Sonnet says it might be an internal conversion module, but it does not give much detail. Currently I do not think it is worthwhile to dig out what it really is.
I think there are fewer in-use encodings that require digraphs than the spreadsheet implies. From what I can recognize, GBBIG5 may be similar to GBGBK. What is ISO646 (as versus ISO646-something), which does not really make sense? On macOS there is an ISO646-BASIC:1983 (I don't see an equivalent on Ubuntu), but it behaves differently than the spreadsheet too.
That table is missing some critical information: how many if these encodings are in common use, and used to write C++ code (or code in general)
Or rather, the question of whether a given encoding needs digraphs is sort of irrelevant, the question is whether digraphs are used.
EBCDIC-derived encodings use trigraphs and we should keep accepting the magical phase one mapping of trigraphs to be a conforming extension.
And if we really want to do encoding agnostic pragma without trigraphs (which there is no evidence of anyone doing today), we don't need digraphs.
As Matthias's research shows, digraphs were a solution to a problem that no longer existed by the time digraphs where shoved in the standard, and because of internalization, internet, standardization of keyboards, OSes, programming languages, communication protocols and so forth, products that don't support the range of ASCII characters would not have been viable, since before the 00s.
Shift JIS is the only popular encoding that is not ASCII compatible but we are all happy to pretend that ¥ and \ are the same character (same for ~/overline). Which is bonkers, but it is what it is. (Tom table also makes that mistake).