Remember that unit tests are not usually representative of real-world usage. Startup and teardown operations are indeed expensive, as can be the repository operations until things warm up.
Infinispan and ModeShape both do tend to improve performance after a warmup period. Plus, as unintuitive as it might be, ModeShape will actually benefit from having multiple sessions accessing similar areas of the repository. For example, think about how ModeShape has to materialize a node: the first session that accesses that node will take the hit of materializing the node by getting the persisted representation from ISPN, parsing the representation to build objects, and then caching the object form into a workspace cache. Subsequent accesses of the same node (from the same session or different sessions) will find the node already cached locally in ModeShape's workspace cache, eliminating most of the access overhead. And just in case you're worried about that workspace cache exposing data that's been changed, the internal object representation (not the javax.jcr.Node implementation, which is simply a flyweight) is purged from the workspace cache as soon as a change to that node is persisted (via any Session.save() calls in any process).
Your comparisons between cache stores are similar to what we're finding. One option to consider is to use asynchronous "write-behind". This does tend to decrease times required to save, but it has other implications that may not be acceptable.