For a programmer without Lisp experience, that would be true. But I've written enough Lisp-based webapps that there aren't really that many 'unforseen' problems for me anymore (rule of thumb: use software by Edi Weitz - everything he writes is golden :-D)).
That being said, I still ran into trouble with Elephant, so I probably should have taken these sort of 'unknown unknowns' (which are more prevalent in unusual languages like Lisp) into consideration upfront. To not do so was certainly an oversight.
It seems like a somewhat precarious decision to let you use Lisp for this project. There's nothing supremely special about the problem you are attacking that warrants Lisp (outside of your comfort level which you clarified very clearly in your post).
Perhaps I'm just old and cynical but I've been on too many projects where the first (and therefore "lead") developer chose a particular language and architecture that in the long term was not sustainable.
As a point of reference, ITA Software has no trouble hiring 100s of Lisp programmers.
Minor correction: I am a founder - and if I were to leave (while my co-founders continued), I'd make a point to find my replacement first.
This one is a tired argument. Any good programmer will grok Lisp (or Python, or Ruby). If your Python/Ruby programmers can't get Lisp from a couple days of training, then they are not good programmers.
And, BTW, I would risk betting they are writing FORTRAN code in Python and Ruby.
This also alludes to the popularity of do-it-yourself microframeworks. If you're planning on using a microframework anyway, I'm not sure your argument really holds up. You can pretty much use whatever not-completely-marginal language you want and be just fine.
Honestly the only valid argument that I come up with is that you can't find enough programmers that know or are excited to know that language to join your team.