If you do not overwrite the previous contents of the disk, any old information will remain in a trivially (software-only) readable form until it happens to be overwritten, which may be a very long time (bordering on forever).
If you do overwrite the previous contents of the disk with zeroes before creating the LUKS data structures on-disk, you have largely removed the possibility of reading old data off the disk (it will be a decidedly non-trivial task using software, but might be possible with specialized hardware, a lot of time and a lot of money) but since the odds of any length of data encrypting to all zeroes is negligible, it is trivially easy to determine which parts of the disk hold actual encrypted data. Hence, a determined adversary can focus on the parts of the disk that actually hold data.
If you do overwrite the previous contents of the disk with random data before creating the LUKS data structures on-disk, it will be very difficult to determine which areas of the disk holds actual data and which are simply noise, because they will look largely the same. (Without the key, properly encrypted data is indistinguishable from noise.) An attacker may be able to tell that there is a LUKS data container there because of its inherent data structures, but won't be able to tell which parts of the disk are worth attacking cryptographically.
If you do fill the encrypted container with zeroes or random data, anything outside that container will still hold the previous data and be susceptible to the same risks as if you didn't do any overwriting of the disk content. With an encrypted container covering the whole disk, this will be a trivial but still nonzero amount of data.
Which one of these is appropriate for you is a matter of risk analysis. Any overwrite takes a good while, but the difference in time between overwriting with zeroes and with pseudo-random data is rather small in comparison.
Overwriting the disk has an additional benefit: it exercises the entire physical area of the disk, allowing the drive to identify and relocate damaged areas before anything important gets written to it. Since with encrypted (like compressed) data any single bit errors are going to multiply rapidly, the potential benefit from this is non-trivial and comes at a relatively modest cost.
I overwrite the entire disk with random data as a matter of course before initializing it as a LUKS device, because I feel the benefits of such an approach outweigh the cost (with the cost being primarily time to first use of the new drive).
If you overwrite the entire disk (using something like
dd if=/dev/urandom of=/dev/sdb bs=1M -- warning, do not run that command unless you know exactly why you are doing so!), then you don't need to do a separate overwrite of the encrypted LUKS partition, because it's already random-looking enough.
And of course, the obligatory XKCD reference: drug him and hit him with this $5 wrench until he tells us the password. But I'm sure you are aware that even full disk encryption is no panacea.