I can see your point, but it depends on how technical their glue work is, if you like.
In the post, she mentions for example:
> The manager has a bunch of teams and is starting to rely on Engineer to know what's going on with this one. Hey, Awesome Coder seems blocked. Do you know what the deal is?
>
> Our Engineer investigates, discovers that Awesome Coder needs information from another team but is mired in a three week long email thread. She talks to some people in real life, figures out what the confusion is, sorts it out. Awesome Coder is unblocked. He says thank you, writes thousands of lines of code.
This sounds to me like she knows exactly what's going on in the relevant part of the codebase to be able to get the information to unblock Awesome Coder.
> A customer comes in with a request: they want data that the API really should be able to provide but the team hasn't prioritised this feature yet. Our friend here spends a couple of days manually getting the data the customer needs. The customer is overjoyed.
Again, it looks like she's perfectly fine writing productive code when you let her.
I've worked with several great people in the past who exactly fit the description of "glue person" - although most of them were male - and I found that mostly, while the Awesome Coder types had an excellent understanding of their own part of the code, the glue people were the only ones who really understood how things worked together. So you got someone in team A saying why not replace libX with libY because it makes our Z easier, and the glue person speaks up and says actually I worked with someone on Team B last week, and they're using feature W of libX.
Tanya herself admits that "is this person a Senior Engineer" is controversial. But I'd say that someone who is glue in a way that clearly demonstrates a deep technical understanding of the codebase should qualify, even if that understanding is not demonstrated by writing her own code.