From what I can see I only have one active path which makes no sense. I have done a similar setup in a test environment and there I see two working paths.
That is due to ALUA. Only the path to the controller actually owning the LUN is actively used by default.
In a storage array with two active controllers, usually only a single controller actually owns a LUN with write access to it. The other controller redirects IOs to this owning controller through an internal backplane link transparently for the initiators. This tends to be an undesirable inefficient process however.
Most storage arrays and ESXi support ALUA in active/active mode. ALUA communicates which controller/targets really own the LUN to the initiator, which then only uses the "active optimized" paths for this LUN by default.
You can see in your initial screenshot that the two paths are listed with one being "Active" and the other as "Active (I/O)". From the esxcli output we also see that the array supports ALUA. You could force the host to use active non-optimized paths as well by setting the useANO parameter to 1, but this is generally not recommended:
naa.600c0ff0001b2dde4926405301000000
Device Display Name: HP Serial Attached SCSI Disk (naa.600c0ff0001b2dde4926405301000000)
Storage Array Type: VMW_SATP_ALUA
Storage Array Type Device Config: {implicit_support=on;explicit_support=off; explicit_al
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0; lastP
Path Selection Policy Device Custom Config:
Working Paths: vmhba3:C0:T1:L2
Is Local SAS Device: false
Is Boot USB Device: false
Your test environment does not support ALUA (besides using being a completely different storage medium), hence it will treat both paths as active by default.
Here is some more general info on ALUA: