The dream is you never have to rely on buggy vendor software again.
The reality is, you end up with a complex stack with no or homegrown documentation that requires experienced engineers to operate and maintain.
In some environments, that's a perfectly fair trade-off. In most, it isn't.
Improvement on this is more likely to come from switchdev than from Tofino & P4. (though these don't necessarily contradict each other)
You can already run plain Debian on a Mellanox Spectrum device, treat it like a Linux software router, and by the power of magic your routes get pushed into hardware. (Source: device on my table to my right :D) Microchip's SparX-5 should be similar though I don't have one of those to test.
That was certainly the case 15 years ago.
The only switching/routing vendor with an API worth a damn was Juniper - in fact they were the only vendor who was applying CLI changes to the box via their own API, the Way It Should Be Done™.
These days you are spoilt for choice (and price point) with the likes of Arista, HPe (AOS-CX), Cisco (NX-OS, IOS-XR) and plenty of others entering the space.
Vote with your wallet!
The APIs these vendors provide are a joke. A bunch of functionality can only be accessed via scripting interactive CLI commands. Some API endpoints cause short downtime / unexpected behavior (eg: by deleting the routing table and adding all entries back 1 by 1), while the on-device commands do not.
And guess what, the switch may decide to print informational or environmental messages interleaved with the command output, because the commands were meant to be run by a human. Good luck knowing if your state-altering command succeeded when you receive broken JSON.
I ended up regex-removing known environmental messages from command outputs..