I want to start off apologizing for the length of this post, but there's a lot to be said here. As usual, there is some simplification here so doing in-depth research will improve your understanding of what is discussed here, and possibly change it.
First, I did a Google search for the term "mips optimization" and it appears to be a term used exclusively by one company - an India-based consulting company. If you want to know more about it, I recommend you contact the company and ask them. It is certainly NOT a standard industry term.
Second, computer measurement, performance tuning, and capacity planning are extremely complicated topics and you're not going to get more than a smidgen of information on them from this or any forum. Visit the Computer Measurement Group website (there are others around) and start reading if you want to know more.
Third, MSU and MIPS are THEORETICAL terms that have picked up practical usage. I'll use as an example the z800-001 a previous employer had. If you check the charts, that machine was rated at 32 MSU or 192 MIPS (I believe the MIPS is down to 188 on the latest charts but haven't confirmed that lately). That means the machine has the capability to process 32 million service units per hour. A service unit is a measure of work (CPU, I/O, storage and SRB are the 4 IBM uses) and many if not most systems will show the service unit usage on the job output. Every 24 hours that machine can process 32 times 24 or 768 million service units of work. As long as that machine is there, that is the MSU for the machine. The only way to change the MSU is to upgrade or downgrade the physical box -- which sometimes can be done in the field by IBM and sometimes requires replacing the box. The -001 means that machine had one engine (one processor) to perform the 32 million service units. The z800 also had -002, -003, -004 models with 2, 3, 4 engines. So if I think I have 125 million service units of work per hour to perform, I could get a z800-004 and be happy, right? No - the incremental service units goes down as the number of engines increases as they have to spend time communicating with each other to make sure nothing goes awry. So a z800-004, despite having 4 times the engines of a z800-001, was only rated at 108 MSU (636 MIPS) not the 128 that 4 times 32 indicates.
Side note: do not assume that 6 MIPS per MSU is a constant -- it varies by the machine. The zBC12, for example, appears to be running about 8 MIPS per MSU.
Fourth, when someone says a job uses 3 MSU (for example), I assume that they have looked up the actual service units used by the job and divided the total service units by the number of seconds the job executed and converted to MSU. If all that has been done, you can -- sort of -- discuss reducing the service unit usage of the job. Any other use of the term MSU for a job is incorrect at best and wildly wrong at worst.
Fifth, the LPAR is running 1000 jobs -- but you didn't quantify that. Is that 1000 jobs a day? week? month? year? forever? And the number of jobs doesn't really matter -- what matters is the CPU usage, channel usage, storage usage, SRB usage and the average / peak usage of each of these values. You could, if the system is set up for it, run 1000 jobs every second and as long as they are short, low-impact jobs you may never notice them in the system.
Sixth, jobs are not usually where the system is most active, even though that's what the applications programmers see. My current employer's system has 4 LPARs defined and allows up to 600 address spaces (batch jobs, TSO users, started tasks, and OMVS processes) to be executing at one time. At any given time, just under 300 of those address spaces are running system tasks (data bases, CICS, RACF, WLM, JES, and so forth) so if some of the system tasks can be tuned more efficiently, that will usually have a larger impact that batch jobs.
Seventh, a computer program is bottlenecked. Always. If it didn't have bottlenecks it could get done in zero seconds and make everyone very happy. Bottlenecks will either be CPU (CPU-bound) or I/O (I/O-bound), where I/O can represent delays due to the channel, or the disk drive, or the control unit, or the tape drive, or the buffering of data, or .... If a program is I/O-bound, you could give it the fastest CPU in the world and the job would take exactly the same amount of time. Similarly, if a program is CPU-bound, changing from tapes to disks to solid-state devices will make no difference to how long the job takes. If you don't know the a given job is CPU-bound or I/O-bound, there is not much you can do to improve its performance since you don't know where to start. If your high-CPU-using jobs are I/O-bound, even though they are using a lot of CPU time, then you won't be able to impact their CPU usage much. If they are CPU-bound, you look at the standard culprits first -- buffers, access patterns for the data, code that is doing too much, inefficient code (which should be near the bottom of anyone's tuning list).
Eighth, performance tuning should (but doesn't always) start from a global approach. Frequently, changing the start times of certain jobs to reduce conflicts with other applications can raise the overall throughput of the system. Performance tuning should be looking at the batch window to see what can be done, as well as looking at the online processes to see what can be done. Sometimes adding a database on a different DASD channel may well speed up online processing, even though overall CPU time goes up because of the additional database. Workload management policies can have a big impact -- I have a system where I changed the WLM policy for batch processing, and the elapsed time for one job dropped from 14 hours to 45 minutes (the second was a rerun so the record counts were exactly the same).
Ninth, the advent of specialty engines muddies the MSU / MIPS picture. A processor (engine) on a system z machine can be a CP (general purpose processor), SAP (System Assist Processor -- dedicated I/O processor), IFL (Linux-only), ICF (Coupling facility-only), zAAP, or zIIP -- and each LPAR can be on a dedicated engine or share the use of an engine. If a machine has 20 engines with 40 LPARs defined on it, with some of these LPARs being CP and some IFL and some ICF and some zAAP and zIIP, the very concept of MIPS starts getting pretty fuzzy -- especially since some of these engines may be running at different speeds.