Transcoding from or to a frequency domain type codec is the most CPU intensive activity normally associated with an Asterisk system.
I note your translation path has three such translations. I’m surprised there is no direct translation from slin to slin16. What is in your codec translation costs matrix?
Given that this translation path goes through slin, there is no quality advantage in using slin16 over slin. G.729 is also an 8kHz codec, so slin16 offers it no advantage over slin.
MixMonitor needs to transcode to signed linear of some form to be be able to work at at all, as it has to add the linear samples together!
Looking at https://asteriskfaqs.org/2012/11/21/asterisk-users/core-show-translation-difference-in-asterisk-versions.html it seems to me that Asterisk may be making some bad routing decisions and using the scenic route between codecs. I can’t see that using g722 as an intermediate is really going to produce better audio than say a cubic interpolation to rate adapt 8kHz signed linear to 16kHz signed linear, and, if the original is G.729, there is no point in sampling faster than 8kHz.
As Jonathon commented in the quoted article, he can possibly say more about why such convoluted transcoding paths are being used.