mavproxy is a program that runs on the companion computer to facilitate communication between the top side computer and the Pixhawk. The streamrate is the rate that it gets parameters from the Pixhawk, so reducing it just means that the topside gets less frequent data updates (the Pixhawk itself still runs at the same internal data speeds, including collecting depth and accelerometer readings and so forth, it just sends updates to the top less frequently).
Main potential issues I can think of are things like heading integration in PingViewer may not be as smooth/effective, and if you’re trying to control precise orientations/motion from the top side (manually or through pymavlink/mavros) then the slower updates can make that more difficult/take a bit longer (it’s easier to overshoot when you have less frequent measurement display updates). In saying that, for human-based control there shouldn’t be much difference between 10 and something like 5 or even 3, and if you don’t need to control precise orientations at all then 2 should likely work fine (as you’ve suggested).
Mavlink itself supports streaming individual messages at different rates, which could be useful here, but I’m not sure if that’s possible with mavproxy - I’ll have to look more into it and discuss with the software team.
@Synchron there are a couple of others who’ve had issues with mavlink using excessive CPU, and we’re working on an update at the moment that should reduce/resolve that, along with some other issues, which (as far as I’m aware) should be releasing this week. If your timeline is more urgent than that then it may be worth reducing the streamrate parameter for now.