Rainbow tables - not well suited to crypt(3)

Rainbow tables are a bad choice for traditional crypt(3) because it has salt. Not enough salt by modern standards, but still a 12 bit salt means your time-space tradeoff in choosing Rainbow tables just got 4096 times worse. You will need to crack many tens of thousands of equally valuable passwords to amortize the additional cost compared with brute force.

[NB the lwn article you linked is about a Windows hash scheme which uses unsalted DES, Microsoft chewed through three or four different lousy password hash schemes before finally getting one that doesn't suck worse than the one they could have cloned from Unix 30 years ago...]

To give some idea of what that 4096 number means in the real world:

If you can afford disk space and CPU time to build a Rainbow table for MD5 that covers the alphabet plus digits (A-Za-z0-9) for up to 8 characters (a lot of work, but enough to reverse many passwords), then if you try salted crypt(3) instead you'll only have resources for up to 6 characters instead.

You will miss any half-way secure passwords this way, which makes it of very limited value.

But the story gets better yet, because the above assumed the two hashes were equally expensive to calculate. But this isn't true unless you have the resources to use custom hardware; on general purpose CPUs crypt(3) was deliberately pessimised, and remains annoyingly expensive in CPU time for brute forcers or calculating Rainbow tables.

So the difference between traditional crypt(3) and MD5 ends up being way more than a constant factor 4096 for Rainbow tables. Enough more that I've never seen a public project to attempt even the somewhat useless six alphanumerics I described above for crypt(3).

Is it possible there's a private project? Yes. Is it likely? Hard to say, ask someone with more relevant expertise. Would it be expensive? Undoubtedly yes. So then is it likely script kiddies would use it to break into Savannah? No.