I wasn’t suggesting that AMD performance may be better or worse than Intel in this application. The only point I was trying to get across is that this is a very old and wimpy x86 CPU. (And also trying to put it in the proper context by comparing it to roughly equivalent Intel parts.) And even though it is not very powerful, it still managed to forward a full 1Gbit/s worth of masquerade traffic without breaking a sweat.
Now I am confused, because before this response, you never mentioned anything about these other two CPUs you were testing on; you only told us about your i9-12900 CPU, and in your original post, you specifically said “the speed received in chr and x86 is 100 megabits”. Now you are saying that in some scenarios, you can “barely” reach 1 Gbps. These are contradictory statements. Either you’re getting 100 megs, or you’re getting “close” to 1Gbps. So which is it?
In your very first post, you LITERALLY said, “the speed of masquerade nat is extremely low, […] is 100 megabits, only src-nat to src-nat has the correct speed and gives the full 1 gigabit”. So again, I am confused, because in your first post, you seemed to be comparing NAT performance of “action=masquerade” to “action=srcnat”. By “src-nat to src-nat”, did you mean something other than changing your NAT rule from “action=masquerade” to “action=srcnat to-addresses=<WAN_IP>”??? I don’t know how else to read “src-nat”. Unless you misspoke and meant that you disabled NAT entirely, and so were not changing src-address at all? If so, that’s not called “src-nat”. That would be called “NO NAT”. 
It indicates you are not being completely honest about your configuration, and what exactly you are trying to do.
In your original post, you mentioned NOTHING about using “random” matcher on your NAT rules, or even that you had multiple NAT rules. You included a configuration example that was extremely basic, and which implied that all you were doing was a single NAT rule, action=masquerade, for one internet connection @ 1Gbit/s. Now you’re talking about multiple NAT rules, using matchers you did not include in your example config, and possibly multiple internet connections for all we know, since you keep hinting at “load balancing” without actually explicitly saying what you mean by that.
As I’m getting fond of saying, nobody here is a mind reader. We can only interact with the things you say out loud, not the things you only think in your head. If you want help either to figure out where the performance bottleneck is, or even to validate that there is some RouterOS bug causing a bottleneck where there shouldn’t be one & you aren’t crazy after all, you need to explain your entire situation in detail (along with a complete config that reproduces the problem you are describing), and not leave us guessing about random crap that you may or may not be doing.
The config I posted for my test rig was the entire config of the router (minus auth credentials). If you are doing something more complicated than that, well, I didn’t test for that since you never explained that you were doing it.
Let’s first be unambiguous on definitions. “action=masquerade” is nothing more than “action=srcnat” except that it automatically decides what to change source address to on the outgoing packet, rather than require you to manually specify it with the “to-addresses=” parameter. I think whenever you say “masquerade”, what you really just mean is “NAT” generally.
Yes, NAT has an impact on performance. This is a given, and also just common sense. It has more computational overhead than just forwarding packets without touching them at all does & without having to track the various active connections flowing through the router. And yes, on a device like RB750Gr3, doing almost any form of NAT will reduce performance down to about 200-300 megs. However, if you use FastTrack, then you CAN get 1Gbit/s of forwarding performance with NAT even on small, cheap RouterBOARDs like the 750Gr3.
Unfortunately, FastTrack is NOT supported on x86, and though this has been hotly debated in other threads elsewhere on this forum, the explanation given by MikroTik at least in the past is that FastTrack can only be properly supported by RouterOS on specific interfaces that use specific drivers. And x86 ethernet hardware does not appear anywhere on the supported hardware list for FastPath/FastTrack.
However, something like RB750Gr3 has a VERY wimpy CPU/SoC, and NEEDS FastTrack to be able to do NAT at 1Gbit/s. But as I believe I have successfully demonstrated already, even a relatively wimpy x86 CPU is still many times more powerful than the CPU in most sub-$100 RouterBOARDs, and if you have a sufficiently fast x86 CPU, you don’t need FastTrack to be able to forward 1Gbit/s of traffic with NAT. The CPU is more than powerful enough to do it without FastTrack.
What we need to know at this point are the missing puzzle-pieces to your config that have gone unspoken to this point, if you actually want any help to solve your mystery.