Thanks for running these tests. The increase in processing time is due to changes in the LZMA codec.
What's going on? Analysis and test compressions to determine the most optimal LZMA compression parameters .. one of the unique features of PECompact. I hadn't publicly revealed that I do this yet, but since you ask -- there it is

So, while it is intentional, you are right that it appears on the tested executables that the extra test time doesn't make much of a difference. Perhaps I should further tweak it to tune down compression times at higher compression levels.
Whether or not its 'worth it', I don't know for certain, but that's what the compression level parameter is for (/cl). Lowering the compression level should decrease the time to compress and probably not hurt the compression ratio in most cases. So, to return to v2.79 behavior, setting the compression level to '3' or '5' should do it. In fact, at the default compression level, it may behave identically to v2.79 -- I'd have to go and check the commit logs to find out exactly what tweaks I made.
As a side note to readers: The compression time and compression level do not directly affect decompression speed. However, in some cases, a higher compression ratio can slightly increase decompression speed because there is a smaller compressed data stream to work with. So, compression time/ratio is inversely related to decompression speed, if any relation is to be drawn.
Thanks,
Jeremy