When you say "unmanaged," I think you mean "default configuration." Yes, it works, but almost certainly not the way you would like it to. By default, all the ports are up and in a single VLAN (vlan 1). There is no routing enabled. You can type "show interfaces brief" to see the status of all the ports.
You obviously have something more complex on your Dell switch. If you can let us know how the Dell switch is configured, we can come up with an equivalent for the HP.
According to the Access Security Guide for your device, the first address and mask of an ACE is source and the second address and mask is the destination. (Just in case, an ACE is an Access Control Entry; that is any line an access-list is made of)
ACE 20 of your ACL states source 192.168.50.0/24 and destination 192.168.101.0/24, then you apply the ACL at VLAN 101 input; however, your VLAN 101 is 192.168.101.0/24, so any input traffic at VLAN 101 would have source address in 192.168.101.0/24. So ACE 20 in your ACL is wrong, you need an ACE with action permit, source 192.168.101.0/24 and destination 192.168.50.0/24.
ip access-list extended "SecureContent"
10 permit ip 192.168.101.0 0.0.0.255 192.168.50.0 0.0.0.255
Regarding the way back for this traffic, it will cross VLAN 101 outbound, so ACL should not be applied to this traffic and it should be allowed.
If traffic back is not allowed then you need to add the way back in your ACL.
ip access-list extended "SecureContent"
10 permit ip 192.168.101.0 0.0.0.255 192.168.50.0 0.0.0.255
20 permit ip 192.168.50.0 0.0.0.255 192.168.101.0 0.0.0.255
EDITED to change the line above to reflect proper ACL structure of numbered entries. (10, 20, etc).
Best Answer
This isn't necessarily a misconfiguration, but likely is.
LLDP carries primary vlan id in one of its attributes to help switches identify mismatches like this.
We have a number of cases were VLAN ids are only locally significant in our equipment and on completely untagged ports, with lldp enabled, the procurves will log these messages periodically because the ports have different VLAN ids on the two switches. It doesn't matter, though because the vlan id numbers are only locally significant on each switch. I wish I could turn off this message in these situations, but alas, I'm stuck with the noise.
In the typical case, where VLAN ids are more than just locally significant, this likely does represent a misconfiguration where traffic could jump from one VLAN to another if the primary VLAN on a port is sent untagged (while other VLANs are tagged).