34 seconds is the "wall clock" time calculated from the log, which is not reflective of what you're getting "charged" for in the CPU limit. Actual limit usage will be less than that. I usually use a System.assert(false, Limit.getCpuTime()) at the end of my code if I want to produce output without a log.
34 seconds is far too much time for this to be running normally. If you tone down the debug settings to:
55.0 APEX_CODE,NONE;APEX_PROFILING,FINEST;CALLOUT,NONE;DB,NONE;NBA,NONE;SYSTEM,NONE;VALIDATION,NONE;VISUALFORCE,NONE;WAVE,NONE;WORKFLOW,NONE
You should end up with a much more reasonable:
External entry point: static testMethod void test(): executed 1 time in 25009 ms
But, that still comes around to why this code didn't crash. After all, it took 25 seconds to run, right? That only accounts for the wall clock time. Scrolling up a little, it looks like I actually used far less:
Maximum CPU time: 13244 out of 10000 ******* CLOSE TO LIMIT
Time spent in the database and callouts doesn't count for CPU usage, but does count in real time ("wall clock time").
Note that the CPU limits are flexible. You're only guaranteed 10,000 ms, but it is not unusual to see values as high as 15,000 in production not fail, and I've observed values as high as 20,000 in Sandboxes. It depends on how heavy the system load is; during busy times, the limits are more strictly enforced.
Obviously, you should try to optimize below 10,000 CPU time used, because even at 5 seconds you can end up tripping over the long transaction limit (10 concurrent requests over 5 seconds).
You're not reading this wrong: only the Apex execution time counts against the concurrent long-running transaction limit. Even if your service took 115 seconds every time, you'd never run into that particular limit. Note, however, that there is a limit to the number of concurrent callouts per org, so with enough traffic, it would be possible for some callouts to be denied, but not because of the concurrent long-running limit.
You can make up to 20 concurrent callouts to endpoints outside of your Salesforce org’s domain. You can make unlimited concurrent callouts to internal endpoints. --documentation
Best Answer
The five second concurrent transaction limit is primarily there to prevent us from consuming too many resources. You can view the 10/60 second limit as a "burst" limit, while the 5 second limit is what we're expected to achieve on average. If your code is constantly running into the concurrent limit issue, you should consider moving some of your processes to asynchronous threads or optimize your code.