This does not have anything to do with Unity anticipating or not anticipating your unique preference for how you'd like it to work. absence of a correct way to move an object due to user input is not a unique preference :)

I'd say that your idea of how you want physics to work is too under-specified to be implemented as an engine-level feature. Let's say an object has a "fixed" velocity of 5 m/s right due to input, plus an extra 1 m/s right due to wind. So that's a net velocity of 6 m/s right. That object hits a perfectly elastic barrier and rebounds to the left at 6 m/s. How does input then layer with this?

Does the input velocity get counted in that rebound, so when we apply our 5 m/s right again plus 1 m/s wind we come to a stop? Or does only the wind part of the velocity count for the rebound, so we actually bounce back at 1 m/s, and continue right at 5 m/s since the wind and rebound velocity cancel out?

Different games might make different choices about which components of the velocity they want to have which behaviour, and since we're well outside the realm of anything that occurs in real physics, it's not the physics engine's job to adjudicate that.

So it just does what real physics would do: lumps all the influences together into one unified momentum state that carries over from frame to frame.

And it exposes a scripting interface, so if you want to compute your own custom velocity using non-physical rules, you can. That scripting interface lets you implement any "correct" version of game physics you can dream up.

For example, in this question, the user wanted to apply collision damage asymmetrically to two bodies in a collision, depending on which one was "responsible" for hitting the other. That's not how real physics works - there's no privileged inertial frame. A moving car hitting a stationary wall behaves the same as a moving wall hitting a stationary car. But using the scripting interface, we can craft that behaviour in our gameplay code.