OpenFlow is a protocol, switchdev is a driver API for exposing access to essentially the same operation model as OpenFlow targets. You don't replace OpenFlow with switchdev, you might use OpenFlow to integrate a switchdev with an SDN
You want to write code that runs on the switch, whether it's a routing protocol or an intent reconciliation loop or whatever. You don't want to send low-level OpenFlow commands over the network because it ends up being slow and chatty.
A considerable portion of SDN craze involved pretty much this. Even systems that didn't use OpenFlow were incredibly chatty, creating complex chains of NextHop routes from centralized or at least semi-centralized servers to the actual switches.
Even in more sane setups, it's not actually uncommon to have control plane talk over network to actual forwarding plane - IIRC Cisco Nexus operates this way, with actual forwarding engines talking with control plane over Ethernet link.
I like the code to run on the switches directly, but SDNs very often eschewed that for dumber forwarding engines controlled OpenFlow way, even if actual protocols used weren't OpenFlow.
