You can drive the clocks from the FPGA if you want to reduce part count.
In general there are two downsides I can think of:
Clock jitter - the I/O pins of the FPGA will add jitter to the clock - this is basically where the clock edges aren't at exactly the right place and as a result the frequency varies by a small amount cycle to cycle (the average frequency is unchanged). However unless you are doing some super critical ADC/DAC/timing operation requiring sub picosecond accuracy, I doubt jitter is a concern. On a 20MHz MCU clock I can't see that this would cause a problem.
I/O Pin Requirements - you end up requiring more I/O pins from your FPGA to be used for clock distribution. If you have enough pins spare, that's fine, but make sure you test that your FPGA can feed a clock signal out of all pins you want to use. Some FPGAs have strict requirements on which pins can be used for clock signal output due to clock routing restrictions. Furthermore if you put your clock outputs on opposite sides of the FPGA you start to increase global clock network usage as the clock has to get to both sides of the chip. The easiest way to find out if this is an issue is to test-compile the design before sending the board off for manufacture.
Other than that, there are advantages to doing so:
Part Count - you need fewer clock distribution buffers or oscillators on your board. Sometimes you can daisy chain the clocks on MCUs if they can feed the clock back out again, but if not you would need to have either separate clock sources for each one which would increase part count. Using the FPGA as the distribution removes the need for discrete parts to do this.
Frequency Control - if you want to change the frequency of the MCU clock you can do the adjustments inside the FPGA (e.g. PLL to multiply/divide the frequency). That could be handy on a general purpose board where you might want to try out different designs. It would also allow different MCUs to run at different frequencies from just one oscillator.
There are possibly more as well, but that's what I can think of off the top of my head.
If you use the FPGA for this, then as I mention above, make sure to go over the design very carefully. Make sure that the I/O standards for the FPGA meet the requirements of the MCUs (and that you have the correct VCCIO voltage for the banks driving clock signals). Also make sure you test the FPGA firmware before you commit to manufacture. At the very least do a test compile to make sure that the design can be fit into the FPGA (both in clock resources and pin constraints) and meet the designs timing requirements.