Hi Ischia,
In my humble opinion I think you're on the right track regarding software versions. Below I have a couple of questions and some notes I took while looking through your sample that you provided (this took me far longer than intended so I included them here just as a history of the investigation). My questions for you are:
What version of the Arduino IDE are you running?
I'm running Arduino 1.0.1 (5/21/2012)
What version of Java are you running?
I'm running
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3646)
You can get this from the Terminal command line by typing
java -version
When I was running Snow Leopard I was using Arduino 1.0 (11/30/2011)
If it were me, I would spend time looking at the versions of software running, and not where I just spent way too much (see below).
=== Investigation notes ===
On my computer I captured a sample (a few times) of an Arduino Upload using the blink program to compare with your sample. The three main things I looked through were garbage collection, exception handling, and anything that was doing any locking, blocking, or some kind of wait.
I scrolled through both stack traces comparing the samples side by side and they are quite similar. Things of note were listed in the summary at bottom
Ischia's environment
Total number in stack
JVM_RaiseSignal calls: 95
Sort by top of stack
mach_msg_trap: 65303
semaphore_wait_trap: 2425
avr6130's environment
Total number in stack
JVM_RaiseSignal calls: 0
Sort by top of stack
mach_msg_trap: 15561
semaphore_wait_trap: 784
As you can see your environment is raising signals where mine is not, but maybe more importantly you have many more instances of functions that are waiting/blocking.
JVM_RaiseSignal could be problematic. It is often used to handle errors at runtime and in that case may perform stack unwinding. However it would probably register in CPU time, which as you've shown is not excessive. Still, in my capture(s) no signals are being handled.
With respect to the "waiting/blocking" functions,
mach_msg_trap and semaphore_msg_trap are functions that wait for some result before the application's process can continue with normal execution. This waiting would likely not register under CPU time, but would definitely contribute to delays.
While all that may be interesting (or not), since you are not developing the code the only thing you can do is focus on the compatibility of the installed software (see point above ).