It has often been called "WebExtensions" or "WebExt" for a long time [1].
I wasn't even aware that it's just referred as "browser extensions" on MDN [2] now (..and the URL still uses "WebExtensions" and it's all over the actual article content. So I don't know.)
To me, 'WebExt' represents a specific specification within the broader category of browser extensions. However, since all major browsers now support this specification (and this only), it has become the de facto standard.
I hope someone more familiar with this topic can provide a more precise explanation
"WebExtensions API" is the genericized term coined by (IIRC) Mozilla, for the (subset of the) originally-proprietary browser extension API surface exposed by Chrome, that non-Chromium browsers (Firefox, Safari) have since added support for in order to be able to support easy porting of originally-Chrome-targeted extensions.
Basically, until ~8 years ago, there were only three browsers of note with browser extension APIs (Chrome, Firefox, and Safari); and they were all proprietary and all different, so developers had to code each extension from scratch for each browser. And developers of major extensions mostly did.
But then Chromium-based browsers like Brave and Opera and Edge became a thing, and they all inherited de-facto support for what they at the time called "Chromium-style extensions." With this, the Chrome extension API effectively "won" the browser-extension-API developer-mindshare war without really meaning to. Developers became less and less interested in porting their extensions, instead opting to just focus on Chromium-based browsers, since not only was Chrome the majority of the market, but Chromium-based browsers comprised a large fraction of the remainder.
Rather than Mozilla and Apple "solving" this by coming up with some artificial new eleventh-hour browser-extension API standard to foist on Google through the WHATWG (that would have required every dev rewriting all their code), Mozilla and Apple both did the pragmatic thing, and "embraced and extended" Chrome's own extensions API, locking in "whatever Chrome was doing at the time" as now being a conventional cross-browser API. That API, going forward, was referred to in the Firefox and Safari docs — and eventually the Chrome docs as well — as the "WebExtensions API" (mostly so that Mozilla and Apple didn't have to say the words "Chrome" or "Chromium" anywhere in their docs.)
A browser saying that it supports the "WebExtensions API", means that it exposes certain browser-extension APIs in JS under the chrome.* namespace, with Chromium-compatible semantics. Yes, Firefox and Safari both present themselves as Chrome to browser extensions, up to and including answering to the name "chrome" rather than "browser" in JS. Wild, isn't it?
Note, however, that these browsers do still also expose their original, incompatible extension APIs under the browser.* namespace. And if you write your JS carefully, you can attempt to make use of these per-browser features in your extension, while gracefully degrading to a WebExtensions baseline.
