Async is a boundary, not a mood
Making every function asynchronous can spread complexity without improving the design. I get better results when waiting for network input is isolated from the code that interprets messages.
The useful question is not whether a function can be async, but whether it must wait. Keeping that distinction visible prevents unrelated application logic from inheriting connection concerns.
Keep ownership visible
Clear ownership between connection tasks and shared application state makes the system easier to test. The compiler's complaints are useful here: they expose unclear boundaries before those problems become runtime behaviour.
Design for failure
Network code has to expect disconnects, partial input, and unavailable peers. Explicit error paths make those cases part of the design instead of surprises hidden behind a successful demo.