One of my first jobs was parsing XML with Regular Expressions. Like TFA the goal was not to construct the entire document tree, but rather extract data. It worked great!
The reason we tell people not to parse HTML/XML/whatever with regular expressions isn't so much that you can't use regular (CS sense) patterns to extract information from regular (CS sense) strings* that happen to be drawn from a language that can also express non-regular strings, but because when you let the median programmer try, he'll screw it up.
So we tell people you "can't" parse XML with regular expressions, even though the claim is nonsense if you think about it, so that the ones that aren't smart and independent-enough minded to see through the false impossibility claim don't create messes the rest of us have to clean up.
One of the most disappointing parts of becoming an adult is realizing the whole world is built this way: see https://en.wikipedia.org/wiki/Lie-to-children
(* That is, strings that belonging to some regular language L_r (which you can parse with a state machine), L_r being a subset of the L you really want to parse (which you can't). L_r can be a surprisingly large subset of L, e.g. all XML with nesting depth of at most 1,000. The result isn't necessarily a practical engineering solution, but it's a CS possibility, and sometimes more practical than you think, especially because in many cases nesting depth is schema-limited.)
Concrete example: "JSON" in general isn't a regular language, but JavaScript-ecosystem package.json, constrained by its schema, IS.
Likewise, XML isn't a regular language in general, but AndroidManifest.xml specifically is!
Is it a good idea to use "regex" (whatever that means in your langauge) to parse either kind of file? No, probably not. But it's just not honest to tell people it can't be done. It can be.
The less like 'random' XML the document is the better the extraction will work. As soon as something oddball gets tossed in that drifts from the expected pattern things will break.
Yeah, I'd almost certainly reject a code review using, say, Python's re module to extract stuff from XML, but while doing so, I would give every reason except "you can't do that".
But in general we aren’t trying to parse arbitrary documents, we are trying to parse a document with a somewhat-known schema. In this sense, we can parse them so long as the input matches the schema we implicitly assumed.
You can parse ANY context-free language with regex so long as you're willing to put a cap on the maximum nesting depth and length of constructs in that language. You can't parse "JSON" but you can, absolutely, parse "JSON with up to 1000 nested brackets" or "JSON shorter than 10GB". The lexical complexity is irrelevant. Mathematically, whether you have JSON, XML, sexps, or whatever is irrelevant: you can describe any bounded-nesting context-free language as a regular language and parse it with a state machine.
It is dangerous to tell the wrong people this, but it is true.
(Similarly, you can use a context-free parser to understand a context-sensitive language provided you bound that language in some way: one example is the famous C "lexer hack" that allows a simple LALR(1) parser to understand C, which, properly understood, is a context-sensitive language in the Chomsky sense.)
The best experience for the average programmer is describing their JSON declaratively in something like Zod and having their language runtime either build the appropriate state machine (or "regex") to match that schema or, if it truly is recursive, using something else to parse --- all transparently to the programmer.
Can regular expressions parse the subset of XML that I need to pull something out of a document: Maybe.
We have enough library "ergonomics" now that it's not any more difficult to use a regex vs a full XML parser now in dynlangs. Back when this wasn't the case, it really did mean the differnce between a one or two line solution, and about 300 lines of SAX boiler-pate.