I'm going to address the question of why one would want to fill a partition with random data before storing encrypted data on it. I don't know what conversion process you've been looking at, so I can't be more precise.
First, if there already was data on the partition that you are making encrypted, and you intend that data to be confidential, you must be sure to overwrite this data. It doesn't matter whether you overwrite with random data or with zeroes, but you might as well go with random (it may or may not be slower depending on the relative speeds of your disk and your CPU). This argument doesn't apply if you didn't have any confidential data on the partition, for example because it's on a newly purchased disk.
Now fast-forward in time to when the partition contains encrypted data. If you do not take any precaution, then an attacker who gets hold of the raw partition can see which parts are not used. This reveals some information: the attacker will know how much data you've stored (to some extent: the attacker won't be able to distinguish between live encrypted data and deleted-but-not-overwritten encrypted data). This is not always a concern, but when you're writing a security tutorial it's better to be safe than sorry. If the unused space is filled with random data, the attacker has no way to distinguish the unused space from the used space (an informal definition of successfully encrypted data is that it's indistinguishable from random data to someone who doesn't have the key).
If the attacker can snoop on the encrypted data several times (sneaking in to read, as opposed to stealing the disk outright), then the attacker can see how the amount and location of used space evolves over time. This too technically reveals information (but not exploitable information in most use cases). Of course, in this situation, the attacker can find out the approximate rate of change in the encrypted data anyway.
The cryptsetup luksFormat
command only stores the necessary metadata, it does not overwrite the whole partition. This is considerably faster, but slightly insecure in some use cases; hence the common recommendation to first overwrite the whole partition.
The standard method to encrypt a partition with LUKS is to back up the data, create the encrypted container and restore from the backup. Thus in the normal LUKS volume creation process, you would overwrite the whole partition, not just the free space (overwriting the free space would not meet the primary objective of erasing the old data, as the new volume may not store the data in the same locations inside the partition). There are projects to make tools to convert a volume to LUKS in place; I don't know how mature they are. In such a tool, you would only overwrite whatever space is not used up by encrypted data at the end of the encryption process.