In terms of performance, speed may not be the only factor worth considering - I'd agree they're pretty close in terms of that.
It's indistinguishable. Remember, the whole form DOM is injected, element by element, using JavaScript, and every interaction with the form, from visibility rules to autofill to pre-fill to checking validity on focus, invokes JS methods. It can take mere microseconds to add HTML5 data- attributes. This tiny overhead is lost in the noise, as you're already firmly within the world of the DOM API (and jQuery on top of that, if you wanna consider other overhead-you-wouldn't-notice-but-is-definitely-there!).
Sure, you could screw up the CSS pretty bad and break the UI but it'd be harder to actually "break" it with CSS. FWIW, issues with future proofing probably aren't something you've got to consider very often b/c your stuff is legendary but I see quite a few things come across in the support space that aren't so carefully considered.
You can functionally break a form using just CSS very easily — by accidentally hiding a required field. Or by failing to test cross-browser and throwing forms out of the viewport... or trying to use ::pseudos + labels to style host objects and making things unclickable. Troubleshooting forms is one of my day-to-day things and there's plenty of CSS-driven (functional) brokenness out there.
Anyway, I love CSS (3+ at least) dearly but you can't build advanced form behaviors without both CSS & JS playing their respective roles. FormsPlus::Tag is just using the published forms API to scan the DOM and add some data- attrs.
.png)