Agreed with Jens, definitely look at your split point usage. In the war that you have, you have a .cache.html file that you mentioned, 4.7MB. In that same dir, there should be a deferredjs/ directory - can you list its contents? It should have a directory per permutation (so, just one, named the same as your .cache.html file), and inside that, there should be some number of .cache.js files. How many are there, and what is their size range (like the .gwt.rpc table you made)?
Odds are very high that a significant number of them are quite small, and so shouldn't be created at all, so you can either remove them from your code (by finding their GWT.runAsync(...) calls), or use the compiler's built-in feature to try to minimize them, `-XfragmentCount=N`. That N is treated as a suggestion, and the compiler will create approximately that many split points in the final output - if that number is substantially less than the number of GWT.runAsync() calls, you probably will see a substantial compile time and memory usage improvement.
If most/all of the split points are small (say, under 100KB), you might consider disabling split points entirely to skip this processing step. There will be an increase in your initial page size, but possibly a manageable one.
But the most important thing when using split points is to measure impact on the user - when you load the page, watch the Network tab in browser tools, and see how much you are actually deferring, how many split points are being loaded, and how big they are. Odds are pretty high that the very last (going by file name) split point is loaded very soon after page load, and that this file is one of the biggest if not the biggest, which itself suggests that some work is necessary to improve your page loading experience. That split point is the "leftover" chunk, and represents any code shared by two or more chunks - using the -XfragmentCount feature is very likely to reduce its size, but modeling how your page loads and application builds is more complex than can be written in an email.
One more simple point: consider turning off the compiler report flag if you aren't actively using the results, it will take extra memory, compile time, and disk space. It would be helpful to turn it back on periodically, but shouldn't be necessary to keep it on all the time for all developers. This tool assists in some of the "why are my split points the way they are" debugging, but if the compile doesn't succeed anyway, odds are no one is looking at it.
Finally, GWT 2.6.1 is more than a decade old - if you're actively developing this application, strongly consider updating.