For spacecraft we are typically building avionics in very low volume - most of the time we're making 5-10 boards, or 10-100 if for whatever reason it's some sort of constellation - I haven't personally worked on a constellation, so they might be buying more for spares or further qualification testing, but the overall point being it's not in the 1000's (or higher). So that in and of itself limits electronics designs to (board) components that are "off-the-shelf".

Typically spacecraft are doing something "non-standard" in the electronics: it's the premise of many space missions, to do something worth doing in space. Most of the time the electronics development done on the spacecraft side (where I've had most of my experience) is to support some instrument or some "payload" that's one of a kind - lots of times those one of a kind instruments have supporting electronics. And lots of times those electronics can be communicated with via standard electrical interface types (for example: EIA485/RS485, LVDS, LVCMOS). However, very rarely is the data protocol, or the temporal functionality standardized. Couple this with significant performance requirements to support the operation of said instruments/payloads (amount of data that they produce, relative timing of several spacecraft components to autonomously control spacecraft attitude, etc..) and a single chip that can both support software for higher level directives (a processor) and programmable logic for lower level and non-standard electronics interfacing (an fpga) seems like a very logical choice.

So long story short: lots of times spacecraft require non-standard data protocols and timing, and due to the typical production volumes and time horizons, doing this development with an fpga/processor combination is very advantageous.