I have now established a work-around on the VMware Workstation 17.0.2 (Windows 11) host and applied additional tuning to my existing Fedora Linux 38 guest installation:

a) enable Fedora 38 init ramdisk for booting not only nvme

cat << EOF > /etc/dracut.conf.d/scsi.conf
add_drivers+=" vmw_pvscsi mptbase mptscsih mptspi mptsas "
EOF

dracut -f -v

halt -p

b) switch controller for existing disk in VMware Workstation

- remove existing NMVe hard disk (this only unlinks it, the backing store remains, your data is safe)
- add new hard disk of type SCSI, pick the original backing store VMDK

- start VM

c) tune for access (optional)

add "noatime" and "ssd" to the btrfs mounts in /etc/fstab

reboot

d) validate

Have plenty of software and data on your virtual hard disk

cd /
rg 1 | wc -l

//exp: no system hangs, obviously no NVMe timeouts
//act: ... exactly as expected, returns a number in the millions

This works much much better than before. Incidentally, it seems as if a (software CI) task which previously took 55 seconds to complete now takes 5% less time (non-scientific measurement) - but really, the important part for me: no 30 second pausing / stalls due to NVMe controller timeouts.

Based on the above, I can only suggest to ignore the VMware recommendation to pick NVMe and to go for SCSI as a fast and robust choice.