It's a commonly used primitive and I'm tempted to do it sometimes, but the problem is that there is no clear semantics. For instance in the blog post, apparently, the author is interested in incrementing multiple fields of the same key, while the proposal on the Github issue, wanted to increment different keys. Unfortunately to extend HINCRBY to make it variadic is hard because the return value would change... At the same time some users may absolutely not want to have all the items returned after the increment, since if you increment a batch of 1000 items and are not interested in the result, to get a 1000 items reply is not great.

Given all this problems, and in order to avoid introducing new commands, probably what could be done is to introduce options into HICNRBY, so that it can model both the variadic thing (only switching to a different reply when some option is given) and also to have specific options in order to switch on/off the reply of the incremented values and so forth.

Commands designed recently, after the old errors, have such capabilities. For instance BITFIELD is pretty powerful, and is a command doing increments: https://redis.io/commands/bitfield