Kernel panics are typically the result of a hardware failure.
In this case we are talking about importing a zpool. A corrupt zpool can (and often will) cause ZFS to crash if there isn't enough redundancy to cover for the corruption since ZFS itself is in the kernel. More than likely the problem is that your zpool has some kind of significant corruption, ZFS tries to mount the zpool, knows something is wrong but cannot fix it. Since it cannot fix it, it simply accepts the data it is receiving and hopes it all works out. Unfortunately, it doesn't and a kernel panic results.
This is an example of why many of us harp so much about "do it right or don't do it". ZFS is pretty awesome. Things work great when you use it appropriately. But if things go beyond the ability for ZFS to correct the issue, the problem is you are flat out screwed. You aren't partially screwed. You aren't limited to using some recovery tool you bought for $50 to recover your data. Your data is locked away, forever, since no recovery tools exist. It's a very big step from "everything is okay" to "my data is irretrievably lost forever". Once you've crossed that line, coming back is damn near impossible. :(
Even without "lots of RAM" a healthy zpool should mount, given enough time, without causing a panic. The exception to this is if you do something like use dedup, or you have so little RAM that you can't even store the primary ZFS metadata in RAM (I think it uses something like 16MB of RAM per device). The fact that you are getting a panic on import.. that's pretty much "worst case scenario" for your zpool.