Consider the following situation.
Process A is running in user mode. In the meanwhile, assume that process B has been in wait state, after having issued a disk read some time back.
Suppose that the disk transfer is complete now, and the disk controller raises the interrupt.
The processor will switch to the disk interrupt handler code. Let us look at the scenario inside the handler.
The interrupt handling is doing actions required for process B, although the system status table will hold the PID of process A.
(In OS jargon, we say that the interrupt handling of process B takes place in the context of process A).
Any subroutine calls made from the disk interrupt handler must pass the information to the callee function that call is for getting work done for process B - not process A.
Hence, at the design level of the kernel, the calling convention of passing the PID has been made uniformly, for most subroutine invocations within the kernel.
In eXpOS, calls to another routine from an interrupt handler is unlikely. - but explicitly passing the PID is a safer interface design.
This reduces the chances of kernel code errors, where the callee function is making updates on the data structures of the wrong process.
Moreover, at the time of the design, the team had to look into the scalability of the interfaces for future enhancements as well.
Thus, the particular calling convention is more of a design level choice, made on general software engineering principles.