Using the Redis Streams wire protocol means any existing Redis client works without changes. The queue is stored on disk, so tasks survive a restart. No new client library to add. One question: if a worker stops in the middle of a task, does the message go back to the queue for another worker?
LOC was never really the point, if anything it's often the opposite. Being able to say the same thing more concisely makes code cheaper to maintain and easier to understand. (Not always: sometimes people are concise just for its own sake, and that's worse.) Either way, that whole debate feels like the past now.
As for metrics based on how much was produced or spent, like companies measuring developer performance by tokens used, that's a dead end regardless. Performance should be measured by outcomes: incident/failure rate, SLA, user numbers and feedback, revenue, that kind of thing.
Agreed, but I think the hard part is the syntax, not the idea. The concept is simple. The way the SQL is written here is unusual, and since there is little training data on it, a model will likely fall back on a more common approach it has seen before.