This is veering into pedantry, but from what I can understand of that setting (I'm not a sysadmin guy but have used MACsec on embedded stuff), that's just as much of an 802.1X feature as a MACsec feature.
Sure the switch will only accept encrypted L2 traffic...but that encrypted link is set up via MKA, which is a part of the 802.1X standard. If you don't have 802.1X authenticating the endpoint, you don't have MKA setting up the encrypted link between that endpoint and the switch and you don't have MACsec.
So if you're trying to prevent a bad guy from getting on your LAN, you need 802.1X, whereas MACsec is an optional extra (a very useful extra if you're worried about MITM attacks). But 802.1X is still doing the heavy lifting w.r.t access control.
You run MACsec either with 802.1X, or with your switch vendor's favorite color of proprietary switch-to-switch 802.1X replacement. MACsec without 802.1X [or equivalent] is a bit like TLS without certificates. It exists in a few places because some people have really weird custom requirements (TLS with pre-shared keys… TLS with NULL encryption…) but those things shouldn't drive a discussion outside their special usage areas.
In that sense: MACsec implies and requires 802.1X. Exceptions confirm the rule.
Sure the switch will only accept encrypted L2 traffic...but that encrypted link is set up via MKA, which is a part of the 802.1X standard. If you don't have 802.1X authenticating the endpoint, you don't have MKA setting up the encrypted link between that endpoint and the switch and you don't have MACsec.
So if you're trying to prevent a bad guy from getting on your LAN, you need 802.1X, whereas MACsec is an optional extra (a very useful extra if you're worried about MITM attacks). But 802.1X is still doing the heavy lifting w.r.t access control.