source-sdk-2013 | The 2013 edition of the Source SDK | SDK library

I think author make wishspeed simply act as scaler for accel, so the speed of currentspeed reach the wishspeed linear correlated to magnitude of the wishspeed, thus make sure the time required for currentspeed reach the wishspeed is approximately the same for different wishspeed if other parameters stay the same.

And reason above that is because this could create some sort of urgent and relaxing effects which author desired for character's movement, i.e when speed we wish for character is big(small) then character's acceleration is also big(small), no matter sprint or jog, speed change well be finished in roughly same time period.

And player->m_surfaceFriction is even more obvious, author just want an easy(linear) way to let surface friction value affect player's acceleration.

From my own experience, when trying to understand the math related mechanism inside the realm of game development, especially physics or shader, we should focus more on the end effect or user experience the author trying to create instead of the mathematical rigor of the formula.

We shouldn't trap ourselves with question like: is this formula real? or the formula make any physical sense?

Well, if you look and any source code of physics simulation engine, you'll find out most of them if not all of them does not using real life formula, instead they rely on bunch of mathematical tricks to create the end effect that mimic our expectation of real life physics.

E.g, PBD or XPBD one of the most widely used algorithm for cloth or softbody simulation, as name suggest, is position based dynamic, meaning they modify the particle's position explicitly, not as one may expected in a implicit way like in real life (force effect velocity then effect position), why do we using algorithm like this? because it create the visual effect match our expectation better.