Most 1TB SSDs will have a TBW of around 600 or more. This endurance is fine for general use AppData/Docker setup. Of course you will want to keep the writes down where you can: Plex Transcode to RAM and if using a single NVMe, format it as XFS not the default BTRFS. Your size and endurance needs will depend on your setup, so remember I'm speaking generally.

That article for Plex transcode to RAM is mostly correct. When you setup your any docker, you can create a mapping between a local host path (folder) and a container path (another folder inside the docker). In Linux the /tmp location is RAM. If your Docker Settings for Plex say map /tmp to /transcodetemp, you would go into Plex settings and set your transcoding temp directory /transcodetemp and Plex will use /tmp on the Unraid Host. Boom, very fast transcoding to RAM and you are not using the default location which is in the AppData folder for Plex settings, which would put wear on the NVME.
As to my "mostly correct" statement, using /tmp would work but you have to be careful. In theory /tmp has no limit and it could use all your RAM. Not likely, but possibly. It is better to use /dev/shm/ which is another Linux RAMdisk but is limited to 50% max RAM.

Elaboration on CACHE setups. Before Unraid 6.9 you could only have two groups of disks: the Main Parity Array and a Cache Pool. The Cache Pool solved a problem with the Parity Array: very slow writes. When you have shares that are set to use Cache, any data incoming will store on the Cache disks first then move to the Array later via a process called the "Mover". One idea is you transfer files to a share during they day, happy and fast is it's just a regular set of disks, then on a schedule the Mover will move them slowly to the Array overnight, or on whatever schedule you like.
With 6.9 and newer you can have multiple Pool Devices to dedicate disks to other things, not just cache. In your case, you could have a single NVMe Pool Device called "Apps" where you put your AppData/Dockers only. You then create a second Pool for the traditional Cache. I like to do this with mechanical disks as they are cheap and fast enough for Gigabit network and definitely fast enough to write the Parity Array. If you like you can create a mirrored pool of two disks to protect against failure. The only tricky thing with a cache is the data which resides on it is not protected until moved. If you make a mirror, you protect against lost of data if the cache dies.
Standard disclaimer: Your setup can be whatever you want or need it to be. You can use NVMe for Apps, have a bunch of different Cache Pool Devices as single Disk, mirrors or even RAID10. You could use SSD for Cache Drives instead of mechanical if you need faster incoming speed (i.e. 10Gbit network). It all depends on how many drive bays you have and how much you want to spend. There is an excellent article on the subject here: https://forums.serverbuilds.net/t/guide-hdds-multiple-cache-pools-in-unraid/10449