Something I've casually looked at is making LargeIntegers just be arrays of SmallIntegers. This way you leverage the SmallInteger primitives and should gain considerable performance -- even with a Smalltalk only implementation (a primitive or two might be desireable to make the shift from SmallIntegers to LargeIntegers and back more graceful). This approach has actually been used in the past in some Lisps (don't know if any still do this). One thing you could do is to simply make negation of a LargeInteger be the negation of each of its SmallInteger components -- which should allow combining LargePositiveInteger and LargeNegativeInteger into a single LargeInteger class, along with a few other nice side effects.
In theory this is great, but in practice I don't see how it can work. If you are going to use only the low 8 to 15 bits, it might work, but I don't see any real savings in speed deriving from that experiment. If you are going to use between 15 to 30 bits (SmallInteger only has 30 bits for positive numbers), then you will have to deal, directly or indirectly with overflows for your multiplication operations, perhaps by breaking it up into pieces and shifting and stuff (slowing it back down), or using an underlying LargeInteger operation to fill in (same thing).
I think building a plugin instead, particularly because a great deal of the existing code in the image can be appropriated (the preamble code needs fixing, but the rest probably can be made to work) is probably not too difficult, certainly for the innermost loops. A profile shows that for reasonably large numbers 90-98% is presently spent inside the innermost routines.
Thus, a plugin could in theory be built (without too much sweat) that wouldn't slow up the status quo much at all, and would run much faster with a plugin installed.
I believe that at the time Smalltalk-80 blue book was written, there probably wasn't much real need for big number computations, and the thing cranked just fine for the usual baby examples. But crypto may be the "killer need" for good, fast, built-ins. Particularly if we can make this seamlessly pluggable for more speed, perhaps this is a worthwhile project.
But we don't need to wait for CS, certainly for the simple undertaking to pluginize inner code for the private longInt routines for Number, if only to take the profiles to see if that is enough to make a real difference.
Of course, we could just write pluggable primitive code for each primitive directly (since they presently all just fail right now) without meaningful cost (although it would likely require some fiddling with Number and some of the coercion code to make SmallInteger + Large---Integer work fast. But why do all that just now?