First of all, you should be aware that you're basically wrong: while there certainly are limits, a modern CPU can execute quite a few instructions simultaneously.
Let's use AMD's new Zen architecture as an example. Its current incarnation supports dispatching (i.e. starting execution of) up to 12 micro-ops per clock cycle (6 integer, 6 floating point--though there's some disagreement about that--some sources say only 4 floating point).
Although that clearly could be increased, doing so would be non-trivial. Just for one obvious point, it's not just a matter of being able to execute more micro-ops per clock.
For integer operations, you need to support 128 bits of inputs for many of the simple ops (add, subtract, and, xor, not), but you have a few operations that need even more (e.g., integer division takes one normal size and one double-sized input, so it takes 192 bits of input operands).
Worse, to get a decent chance of actually executing more ops per clock, you need a larger pool of decoded ops available to dispatch. You also probably need to have even more physical registers (AMD's current design uses 168) to support more register renaming and give yourself a chance of finding more ops to actually execute in a given clock cycle.
So, your design quickly balloons. Right now, AMD apparently needs around two dozen 168-input MUXes to retrieve inputs from the registers into the execution units (of widths varying from 64 bits up to 256 bits), and another dozen (or so) demuxers to store the results.
If you wanted to double the possible execution rate, you'd obviously need to increase the number of MUXes from two dozen to four dozen. Worse, however, to give yourself a chance of actually executing more instructions, you'd want to increase your physical register bank from 168 to somewhere around 336 registers, so not only do you need twice as many MUXes, but each one becomes substantially larger as well. Likewise, to store your results, you'd need to bump it up from one to two dozen demuxes--and, again, each one would need to get larger to support more physical registers.
Then you have the fact that you can currently only decode 4 instructions per clock. If you want to execute 24 ops per clock, you probably just about need to be able to decode around 8 instructions per clock--being able to execute 24 micro-ops per clock won't gain much if you can't decode that many.
Unfortunately, x86 instructions are not easy to decode--so doubling the number of decoders is a pretty expensive proposition as well.
Bottom line: a decent CPU design depends on balancing resources throughout the design. If you want to be able to actually accomplish anything by being able to dispatch more ops per clock, you're going to need to make changes throughout nearly the entire design.
All of that, of course, could be done--but it starts to use up a lot of silicon very quickly. At the present time, it would appear that you gain more by Using that silicon in other ways (more cores, bigger cache, more memory controllers, more PCIe lanes, etc.)