"It's a demo bug, and it's pretty obvious what's going on if you know how demos work. Non-POV demos are just disgustingly inaccurate as the precision of the view angles is getting truncated. The demo doesn't actually contain that mouse movement at all, all it contains is him moving between 3 different points across 2 ticks. The reason those points all line up is because the angles get rounded down to 0.35 degree increments (roughly the width of a head at that distance). The linear movement is the result of the demo player filling in gaps."
"Okay I understand what you say you believe is going on. Can you now prove that's what's happening in this case? Also wouldn't there be a lot more clips as seemingly incriminating as this one if what you described is a common phenomenon? Not saying you are wrong just asking"
"Now that I think about it, I don't even have to mess around with demoinfo for this one, to correct myself though, it actually occurs over 5 ticks: Load the demo up and "demo_gototick 117923", that's the tick the flick begins on. Advance a tick and you'll see his yaw change by exactly 0.35, stay there for another two ticks, then pitch up by 0.35 degrees. Now, where does that 0.35 number come from? That's actually the precision of the angles in non-POV demos as they're stored as 10-bit fixed point. It's not actually possible to represent a smaller angle change, and his entire movement gets rounded down to those intervals. If you want to verify the 0.35-step thing, just look at any GOTV demo, the angles will always be multiples of 0.35. And if you want conspiracy fuel, they are 11 bits in most other source games and were a 32-bit float in CSS. This is why it's practically impossible to spot a good aimbot on a serverside demo."