Raspberry Pis have certainly been designed into cubesats but have not tracked down any overall listing of number actually launched, how well they operated or any lessons learned.
Related questions include this one on Pi's and this on code design.
The three questions overlap, and tie back to hardware design. Hardware side the first task is to ensure the the presumably COTS CPU board is not exposed to environments that degrade/destroy it - mostly by stabilizing temperature. The second part is to provide a a robust support service for the CPU board - stable power, input protection (better to kill an input buffer than whole CPU), watchdogs and redundant storage and of enough smarts to run things while main CPU is recovering.
Rebooting the CPU does not directly help reliability, but design must assume that CPU could reset at any time and include a recovery path for as many as possible failure states that get back to operating, so having automatic hardware driven resets are a one stop shop solution to bugs that lock the CPU rather than individually chasing down those bugs. Do need to avoid blindly going down this path if automatic resets will disrupt time critical operations like landing. Reset process also needs to be able to detect and recover from as many data corruption types as possible, both those from the environment and those left in old data when previous version crashed.
In terms of likely failure points there does not appear to be a summary available on things that killed COTS boards during testing. The anecdotal examples include electrolytic capacitors (being fluid filled burst or dry out), thermal flexing breaking solder joints, hardware assuming convection heating needing additional conduction cooling, vacuum allowing very large static charges to build up and then discharge across sensors and the radiation driven random faults and permanent failures in silicon.
