Not getting much activity on the Salesforce Community site with this one so I'll try it here. I've noticed a massive spike in CPU exceeded limits since Summer 15' and Winter 16'. I've personally looked into the debug logs for about 10 of these (at customer sites) and it seems like the process builder, and workflows allows the end user to build processes that exceed the CPU limits and the first trigger hit after the workflow throws the exception. It doesn't matter if there is just a single line of code in the trigger to get/set a variable - it just throws the exception.
In my case it is a managed package. I can uninstall my package and the next package in line hits the limits on entrance.
From everything I can tell it is like the process builder and visual workflows are allowing people to build what ends up being very poorly written code behind the scenes (crazy recursion etc) and not respecting the CPU limits (stuff you could not get away with in actual code without hitting a CPU limit exception) then upon exit all of a sudden any custom trigger or code pays the price.
Example from the logs:
Exit workflows - message Maximum CPU time: 17895 out of 10000 ******* CLOSE TO LIMIT Enter managed package - set one single variable - just a boolean CPU limit exceeded
Last time I checked that should have thrown an exception before it got down the chain any further (it is 7.8 seconds over the line). So is Salesforce just exempting the users from the limits in Process Builder and Workflows? If so that makes life hard for anyone else after those processes complete. i.e. any managed package or custom code.
My thought is that Salesforce should in fact throw an exception rather than kicking it down the line.