I think i know why, it's because zsh's RANDOM tops out at 32,767, but this insures that the first digit of a string of random numbers isn't random but strongly weighted to 1 and 2, with 3 also weighted. Is this worth worrying about? I'd say so. Perhaps it should max out at 10,000 or 100,000 or even offer a user selectable range? Or do we have other tricks for coping with this? I find zsh to be quite competent mathematically so having to use an external utility to get really random numbers seems not up to snuff.
Also note, RANDOM *isn't* random. It's
a predictable, repeatable sequence of numbers that looks
random. No computer produces truly random numbers. In large
part because random is an analog function and computers are
inherently digital. But some sources are better than others.
Most systems these days come with a
really good source of "random" numbers called a
Cryptographically-Secure Pseudo-Random Number Generator
(CSPRNG). The classic device file access is /dev/urandom,
though most systems offer a programmatic access to the kernel
random pool.
zsh/random uses one of these programmatic interfaces to the kernel random pool and provides the zrand_int and zrand_float functions and the SRANDOM parameter (same as bash) which returns the decimal representation of a 32-bit integer instead of a 16-bit not random number like RANDOM. (RANDOM's behavior is at least traditional across shells if not explicitly part of the POSIX standard)
Check out the zsh/random module in the current test release and the zrand_int math function.