This is probably the first thing you have heard of (/going to hear). Service workers (by those, who have heard of them, at least), are mostly known for being a replacement for AppCache, and bringing offline support for web applications. Some developers tend to respond to this by "we already have AppCache and it works all right", but truth is, several quirks and footguns await for those who dare to try to enhance their app with offline support by using AppCache. The declarative manifest file might also seem easier to handle, but the lack of flexibility that stems from this declarative nature makes it pretty hard to accomplish more complicated offline functionality. Service workers come in at this point, providing a lot of key basic principles (some of them just being specced, either as part of the specification (Cache API), or outside of it (Fetch, URL, Storage API)). These key princibles/building blocks and their well-defined interactions make it possible for web developers to expand on the platform-provided functionalities to their own liking, accomplishing their own needs.
Even if your webapp doesn't need offline functionality (it's based around a service, so it needs to be online to be useful - a bit more on this later), you might still benefit from having a service worker. Just as you'd benefit from a properly set-up AppCache manifest, or even properly set up caching headers, you could use service workers to enhance your application's performance, user experience. Caching assets, precaching predictable pages/paths, offlining data and providing local "autocomplete" results and cached older feed entries until networked API requests complete are all improving the real and percieved performance of your application, both being incredibly important from your prospective user's viewpoint. Through smart caching, moving computation to the client side, prediction and other methods it is not only your user's experience you are improving on -- but you are saving network bandwith, server load and on the long run improving user experience (due to improved responsiveness of the less burdened server ecosystem) by spending less.
What does offline mean? Operator's network being down due to hailstorm? Hiking at Mount Etna? Flying above the Antarctica in a wingsuit? Well offline could be caused by anything. Large metallic structures, overloaded networks, underground, bad reception... What's even worse is being "barely online". Crappy internet - as said by Matthew Inman of The Oatmeal - is way-way-way worse than no internet. You are seemingly online, but your phone can not send. Your e-mail ends up unsent, your tweet garbled, your photo half-uploaded. Apps mostly handle these situations, but webapps just tend to beachball endlessly in a never-ending throbber you can not even cancel, unless realoading the page, which then, of course will get rid of all the formdata you painstakingly just typed. ARGH. Yes, it's frustrating - that's exactly why you should make your (web)apps offline first? Writing a tweet? Save it! Save it often. Send it when there is (good) connection. Posting an image? Save it. Did it fail to upload? Try it again later a few times, maybe it was just an intermittent interruption in the network.
The Background Sync API lets you do all those above which are implemented in (better) proprietary apps: it provides you with the primitives to easily store data until it could be delivered, also serves as an inbox for your incoming data. Data inbox/outboxes are synchronized on select intervals automatically, request from the user or to a server-sent event (generally, a Push message). All the primitives are created to make sure no data loss could occur.
Network information transfer is hard. You could keep a connection open, and poll a server, but that's going to have adverse effects on your battery life and dataplan. Push Notifications help you receive timely events from your server, "pings", that new information is at your service. You could then respond by showing pop-up notifications, or starting a new data sync, keeping your webapp (and its user) up to date.
Whether it is polyfilling future web platform features (see the workshop on creating your on service worker!), emulating remote APIs, optimizing application load, rendering and localization like Firefox OS does or Geofencing (which is a new experimental spec, based on service workers) -- service workers are just laying the groundwork. They are scriptable proxies, a "bedrock API", exposing the "magic" behind your daily browsing (network fetches, caching...). A primitive you could use to "roll your own" solution. Of course, "with great power comes great responsibility" - spec authors and browser implementors try very make sure nothing could go wrong, and the API could not be abused, but you should take care and use these powerful tools responsibly.
Service workers are a new and experimental technology. But it's already shipping in some browsers (Chrome has some of the API since early 2015 shipping in stable). That also means the feature is unavailable for a lot of the users who are going to use your webapp or website. You should provide fallbacks for these users -- even so, you should build for these users, and provide SW-based functionalities to users who could take it, so nobody is left behind or staring to a white blank window. Make sure you do feature detection, and not browser sniffing to decide who to provide the enhanced experience with, so new browsers joining in the future could automagically have the new experience from day one of their release! Service workers are also unstable. That means, even if you use them, be prepared that sometime they could break, or change in ways you haven't accepted. Breaking could not really be circumvented, young volatile APIs tend to be a bit on the brittle side of the spectrum. Be prepared. Also, follow the specification, as it could change in ways that require you to modify the application. These breaking changes are rare, but certainly not non-existent.