And does it truly only increase the amount of memory needed if the image is on an NFS server?  It makes sense that it wouldn't increase the memory required when served up by HTTPS because the system had to copy it into memory in any event.  But, why not when the image is on local media, like a CD, or USB storage device?

This option vasically does
 dd if=$SQUASHED of=/run/initramfs/squashed.img bs=512 2> /dev/null

So my suggestion is just to drop the part about NFS

Using this option when the stage 2 image is on an NFS server increases the minimum required memory by the size of the image by roughly 500 MiB.
-> 
Using this option increases the minimum required memory by the size of the image by roughly 500 MiB.

There is still a *slight* grammar issue with "by the size of the image by roughly 500 MiB."


I would phrase it like:
~~~
Using this option increases the minimum required memory by the size of the stage 2 image (roughly 500 MiB).
~~~

But that number appears to be wrong.  /images/install.img seems to change between releases.  In RHEL 8.1 it was 499.1MB, in 8.5 it is 706.9MB, in 9.0beta it is 637.4MB.  Is it worth it to even put a number here, when it changes?  

How about:
~~~
If the rd.live.ram option is specified, the stage 2 image (images/install.img) is copied into RAM. This increases the memory required for installation by the size of the image.
~~~

That conveys the correct information, points customers where to look to obtain the correct size, but doesn't provide information that will become stale, or have to be updated with every release.

Thank you for confirming +kasmith. Here is the link to the documentation with updates.  

Here is the link to the published document: 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/performing_an_advanced_rhel_installation/index?lb_target=production

No more updates are pending in this regard, hence closing this issue. In case any more updates are required, feel-free to reopen the issue or open new one. 
Thank you :)