[Nexus 5X General] sfhub:
It isn't "required" to root. The SuperSU default installation will essentially make the same changes on-the-fly to whichever boot.img you have installed. You might prefer the modified boot.img because it is slightly simpler to work with custom ROMs and/or system-based root.

If you want to maintain an unencrypted userdata partition, you must have the mount tables in the boot.img/kernel modified to not specify forceencrypt, otherwise upon first boot, your userdata will be encrypted.

If you ever boot with an unmodified boot.img (for example you flash the boot.img from the next security update), it will encrypt your userdata during the INITIAL boot process. What this means in practical terms is if you want to decrypt the (now encrypted) userdata, you will need to back up, install modified boot.img, reformat userdata, then reinstall. If you want to avoid this hassle of your userdata getting encrypted by accident, you must NEVER boot using a stock boot.img.

How you want to achieve the changes to the mount tables is up to you. You could use a pre-modifed boot.img (that Tigerstown has graciously provided), you could install SuperSU using TWRP and have it modify your existing boot.img on the fly, you could use FED patcher to modify your boot.img, you could make the changes yourself by hand, etc.

If you simply want to run root with an otherwise stock system, the simplest method IMO is to just flash the new stock boot.img (and system.img, vendor.img, etc) that came with the update using fastboot, then do NOT reboot when done, instead boot directly into TWRP recovery, and reinstall SuperSU.

This will leave you with a modified boot.img (ie forceencrypt disabled - so your unencrypted userdata will be preserved, and dm-verity disabled - so you won't see the RED corrupt warning) and a systemless root installation (meaning root is installed, but the system partition is left unmodified).

Keep in mind if you are coming from a previous phone without verified boot (dm-verity), there is are merkel hash-trees packaged with the images, spanning every block on the vendor and system partitions. Once any block changes (and dm-verity is enabled) you will receive a RED corrupt warning. Something as simple as mounting /system read/write but making no modifications will trigger the RED corrupt warning because the mount times in the superblock will get updated. The only way to avoid the RED warning message (while dm-verity is enabled) is to never mount /system or /vendor read/write. The RED warning is not game over, it will just display the warning, pause for maybe 5 seconds for you to terminate the boot, then continue.

If you disable dm-verity in the mount tables, then you won't see the RED corrupt warning even if you make changes to /system and /vendor partitions, but you will still see the YELLOW can't verify your software warning, as long as you have the bootloader unlocked. Again, this warning is not game over, it just displays the warning, pauses around 5 seconds, then continues the boot.

The 5x actually has the bootloader unlock done a little differently than older devices. Before you just booted into bootloader and did fastboot oem unlock. On the 5x, you must first "enable bootloader unlock capabilities" by enabling "OEM unlocking" within developer options once Android boots. This setting is then stored in an area that will survive factory resets.

As long as you have "OEM unlocking" enabled (only one time is needed), you can lock/unlock as much as you want, even if you can no longer boot Android.

However be aware that on the 5x (unlike some previous devices) unlock, as well as lock, will force a factory reset for security reasons. On past devices, only unlock forced the factory reset, you could lock the device without the factory reset.

As to whether you'd want to use an unencrypted userdata partition at all, in my testing, there was no real-world (vs benchmark) noticeable difference between encrypted and unencrypted userdata partition since March MHC19J release. Prior to that there was noticeable difference. YMMV.

If you are running Android N, you probably should leave userdata unencrypted as TWRP isn't able to decrypt the userdata for an Android N installation, which means you can't really backup/restore using it nor can you install SuperSU (unless you leave userdata unencrypted)

Modified boot.img and systemless root worked with Android Pay till a couple of days ago. They modified something in the security check that caused it to break. I didn't look into what change they made, but I suspect it can be worked around once people look into it. Be prepared it might be a cat/mouse game where every 3-4 months it will break and you'll need to make some change to fix it.

It is mostly the same, with the above caveats. Even modified boot.img is not really required because SuperSU install will make the changes for you.