To expand on the previous entry, there's a number of factors that influence how fast Unix script languages and programs written in them can start and whether it matters.

First off, people are generally not going to notice interpreter startup delays today, on normal hardware. Modern hardware is more than fast enough to get script startup time below our perception threshold, and most modern Unix machines are under low load with plenty of free memory (when they aren't, people sort of accept that everything is slow). There was a time in the past when interpreted programs were so slow to start that people noticed, but those days are over unless you have a really heavyweight and slow to start interpreter.

(It's possible that Java still qualifies, but I'm not sure.)

However, programs may well notice this extra delay and be affected by it, and this include shell scripts. How much so depends both on how much slower the interpreter is to start and on how many times the other program runs your interpreted program. If you're writing a program that will get used all over the place in your shell scripts, even a relatively small difference can add up. And this obviously matters if you're in a critical path that needs to run as fast as possible for latency reasons.

Resource constrained environments magnify this interpreter performance difference, possibly drastically. The simplest way to get a resource constrained environment is to have your system be under load, especially significant load; this is the classical 'Slashdot melted down my inefficient blogging system' problem. These days you may also be resource constrained because you're trying to run in a small virtual machine instance.

As commentators on the the previous entry noted, this penalty varies with the specific interpreter and with the size of your program, because the interpreter generally has to load and parse all of your program (and libraries that it depends on) even if it will never run most of that code. Various sorts of lazy loading can help, but language semantics sometimes rule them out (or at least require you to code them explicitly instead of taking the easy, language supported approach). This sort of slow startup isn't exclusive to interpreted programs, but it's generally rare that a relatively small compiled program has to do a lot of hidden initialization.