1) True, almost free in comparison to the work done in the transforms.   
      See https://github.com/bazaarvoice/jolt/pull/76, where I think this has been resolved.   Aka, instance of checks only at construction, and no more silly two lists.

2)  No.   Back when Jolt was still part of it's "parent" project, I created a small test case out of a very large, proprietary JSON config file, and ran that transform in a loop 100k times as my "poor mans" performance test.   The runtime of that test was cut in half by three changes.   The most important one being, avoiding Regex in the StarPathElement logic.
What we need is a set of large JSON files to transform repeatedly....

3) Agreed.  But it is nice when things are fast.   I got some attitude early on, eg "Why are you doing this, why not just write the transform straight up in Java?".   There is overhead in learning and operation-alizing Jolt in a project, that I think is clearly won back by savings in "developer time".    That said, I wanted to just nip any "performance" objections in the bud.

Also, can you do a rebase squash of this, and then I'll pull it.