Design philosophy - why use a VAR for a single return value?

[Alice Osako]

    I am changing the API for
      CardBitOps to eliminate all VAR parameters for any case where only
      a single value is returned. 
      
      I am baffled as to why the original design used them in the first
      place, and dealing with that bad design decision was driving me up
      the wall. 
      
      It is a basic principle of software design to minimize side
      effects. VAR parameters are by definition side effects. While they
      are justifiable in many instances, as a rule you should never
      modify a parameter when a return value is feasible. I would expect
      everyone to understand this. 
      
      I didn't want to do this, as I intended to maintain compatibility
      with the existing M2 R10 API, but after the nth time having to
      create a temporary variable solely to keep the procedures from
      altering a critical argument which needed to be preserved for
      later use, I simply felt that this design wart needed to be fixed.
      
      Benjamin, I don't want to step on your toes here, but I do see
      this as something that can and should be changed. Was there a
      reason why they were defined this way in the first place? Am I
      missing something? Or was this a legacy design that needed to be
      maintained for whatever reason?
      
      I apologize for the harsh tone of this post, but I really felt
      this needed to be addressed.