The short answer to the question in the title is NO, backup speed and restore speed are no longer related. There are a number of reasons why this is the case.
Let's go back in time to understand the historical reasons behind this question. Historically, backup was a batch process that was sent to a serial device. Various factors led to the commonly used rule of thumb that restores took 50% to 100% longer than the full backup that created them. This started with the fact that a restore started with first reading the entire full backup, which at a minimum would take the same amount of time as creating the full backup. Then once that happened multiple incremental backups had to be read, each of which added time to the restore due to them time involved in loading multiple tapes. (It wasn't that long ago that all backups were to tape.) Also because backups were sent to tape, it was not possible to do the kind of parallel processing that today's restores are capable of.
The first reason why backup and restore speed are no longer related is actually negative. Today's backups are typically sent to a device that uses deduplication. While deduplication comes with a lot of benefits, it also can come with one challenge. The "dedupe tax," as its referred to, is the difference between a device's I/O speed with and without deduplication. Depending on how dedupe is done, backup can be much faster than restore and vice versa.
The second -- and perhaps more important -- reason why backup and restore speed are unrelated is that backups and restores don't always use the same technology any more. Where historically both backups and restores were a batch process that simply copied everything from A to B, today's backups and restores can actually be very different from each other. A restore may not even happen, for example. If someone uses a CDP or near-CDP product, a "restore" may consist of pointing the production app to the backup version of that app until the production version of that app can be repaired. Some backup software products also have the ability to do a "reverse restore" that identifies the blocks or files that have been corrupted and only transfer and overwrite those blocks or files. That would also be significantly faster than a traditional restore.
One thing hasn't changed: the only way you can know the speed at which a restore will run is to test it. Sometimes the more things change the more they stay the same.