Not really. It's because the interfaces in C tend to follow a common pattern that verbose variable names can get in the way. If we have
int alter_struct(some_struct_t *s, void *xp, size_t xn);
then it's pretty obvious that the data pointer xp with size xn is going to modify whatever struct object we have at pointer s.
The variable names can be shortened because the function interface follows a common convention.
The really important thing here is a good function name, not a good name for the data pointer argument (a descriptive name could even incorrectly suggest it has a specific type rather than simply point to bytes).
"The data pointer is going to modify the struct" is not the only information that is useful.
Again, it is true in every language that there are some basic patterns to what interfaces look like. That doesn't tell you anything about what the application-specific logic implementing those interfaces is intended to do. For that, it is useful to name things such that they describe what they represent in the domain of the application or library.
If it is a generic function, there are good names for that as well (for instance, some kind of copy function would still have meaningful names like "from" and "to").
But the example given by the author here was not that, it specifically acted on transactions. In that case, the input bytes were meant to represent a "raw transaction" and the output struct is meant to represent a "transaction".
The variable names can be shortened because the function interface follows a common convention.
The really important thing here is a good function name, not a good name for the data pointer argument (a descriptive name could even incorrectly suggest it has a specific type rather than simply point to bytes).