Originally, exposure of APIs to JS was done using the XPConnect JS/XPCOM bridge in Firefox. Simplifying a little, XPConnect is not thread-safe, so exposing APIs to workers required manually writing code using the SpiderMonkey JS API. This was done in an ad-hoc fashion for a while. Additionally, XPConnect allowed JS code to be written to expose functionality to content on the main thread, but was basically a non-starter on the worker thread because of the lack of XPConnect. (Simplifying slightly again, XPConnect also provided required security protections.)
Between having to write thread-safe code and custom JS exposure, the overhead could be significant. This has now been greatly improved through the use of automatically generated WebIDL bindings, although C++ is still used and threading issues do have to be dealt with (usually by remoting a runnable to the main thread), so worker versions of an API still aren't free.
New Web APIs implemented by the platform team should usually be designed from the ground-up for worker exposure and have worker support land soon-after or at the same time as the main-thread support. Experimental APIs related to Firefox OS and developed by Firefox OS Gaia teams are more likely to be prototypes implemented in JS for rapid prototyping and will need another rev before they can be exposed to workers. This last bit frequently happens as part of an effort to standardize the API informed by the prototype.
Links for context:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/...
https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bind...