Yes internally. Somewhere deep in the bowels of the akka code, they are communicating state between threads (last I checked they were using a java concurrent queue by default).
At a bare minimum the changes to the location of the head/tail of a queue will need to be visible to multiple threads requiring volatile variables.
The java concurrent queues don't actually use synchronization blocks, they use native CAS operations but thinking that akka removes shared thread state entirely is dangerous.
Even lots of low latency standard Java is tending towards single threaded non blocking models without synchronisation.
The costs of synchronised blocks is high on the JVM. They defer to the operating system for thread scheduling, they enforce a memory barrier meaning all data is flushed out to RAM rather than CPU caches, and multithreaded code dirties CPU caches, reducing performance.
More server side code should be single threaded than not in my opinion.
You can write lock free algorithms that are not single threaded as well. If you design your system so that only 1 thread is doing the writing of data you avoid a lot of the negative performance implications you mention.
That said, I completely agree. Many times making a single threaded system faster will improve performance vs making it parallel.
It could be just me but I think the author should've mentioned alternative concurrent programming models available for JVM such as Akka.