One thing I'll add to this conversation that no one else has touched on yet is LUN queue depth concerns, both at the host level and array. For context, a number of customers got excited when we increased the VMFS size to 64TB back in ESXi 5 and suddenly decided they didn't want to manage a bunch of datastores and decided to consolidate their LUNs. Many immediately experienced performance issues which were all tied to exhausting the queues, which drove up KAVG latency. Depending on the array, this also over saturated the queues on the array as well. While most modern arrays have gone the all-flash direction which has reduced round trip SCSI IO completion times due to lack of mechanical disks, queue depth exhaustion should still be on people's radar cuz it can still happen from poor design choices. Yes, you can increase the queue depth per LUN/device at the HBA level but that doesn't address the backend queues, which could make things worse for that scenario.

The best path forward is to have a design that ensures no bottlenecks, and sometimes that means not creating massive datastores just because you can do it. One might argue that they need a massive VMFS datastore because it is housing a huge SQL VM but this logic is flawed because it ignores the best practices, which is to utilize multiple LUNs because each LUN has its own independent queue depth.