I'm not sure it makes a difference, but I'm also not sure loading that pointer from the command buffer instead is necessarily better/faster than loading it from a fixed table.
We would need to load the id from the command buffer, so loading the function pointer directly from there is certainly faster, though the difference may not be much. It depends mostly on whether the lookup table ends up uncached by the time Vulkan has handled the command. Also, I would like to avoid an unnecessary extra step, even if the result is not quite consistent with other code. Are there other reasons for doing this? Making that kind of change to all 34 commits is very time-consuming.
Well, I've found the operation IDs helpful before when debugging command buffer issues. In principle a function name could be derived from the function pointer as well, but it's quite a bit more painful than just printing the ID in a trace.
The broader point here is that "well, performance" on its own isn't a terribly compelling argument to justify design decisions; unless it's something particularly obvious, it really helps to have the performance data to back it up. In this particular case, my expectation would be that the hard to predict indirect call itself would be much more problematic than fetching the pointer. I may very well be wrong about that, but as it is we don't know that.