At best it's an exercise in specification pedantry. The only reason instruction barriers, fences and serialization instructions seem to make sense in docs is that someone at the architecture sat down and wrote a memory and execution model that can be abstracted by whatever API it is they present to the user.

And someone doing performance or exploitation work at the level of the linked article really needs to understand that model, not the API. (Though you're absolutely right that this particular article seems to be a bit mixed up about both)

I certainly agree that you need to understand the architectural model to write reliable (and cross-cpu portable code) -- and the architectural model for Arm does distinguish barriers from cache maintenance -- though if you're writing exploit shellcode then "works most of the time and we can't do better given the way the bug we're exploiting to get code execution" is sometimes what you're going to end up with, at which point knowing what the specific hardware is doing can help.