If your add-ons are e10s-ready they will, I suppose, survive for some long period, until the anticipated final deprecation day for all the traditional add-ons.
When you do not have to support older Firefox versions (e.g. ESR or non-Mozilla builds)
When you do not have to support anything other than Firefox (e.g. Thunderbird, Seamonkey, or forks) It may and should change in the future
No real UI is available for Android (Fennec) right now
When all the APIs you need are already available
When you happens to port a G. Chrome extension to Firefox
You do not have to support G. Chrome to use the WebExtensions APIs
High-level APIs from the Add-on SDK
When you have to support older (but not too old) Firefox releases
When the add-on is nothing more than a button and a content script
No serious support for Android, Thunderbird, etc.
No clear plans for deprecation
Low-level APIs from the Add-on SDK, or bootstrapped (restartless) non-SDK add-ons
You need to support e10s (multiprocess Firefox)
No direct content access from the main process
Frame scripts, Inter-process messaging, etc.
Not affected when you do not use low-level APIs for content access
Not everything can be made restartless, but if you are not sure you are probably unaffected
You can use js-ctypes, JSMs, and XPCOM!
Traditional overlay add-ons
Who knows?
The zen of the traditional add-ons development for more than a decade
Multiprocess support mandatory (see above)
Guaranteed to remain available through 2017
Probably you should not be using native components
(Future) Native.js with WebExtensions
Use XPCOM and JSM from WebExtensions indirectly
Guaranteed to break (you need to update your use of Native.js all the time)
No concrete plans published
Multiprocess Firefox does not necessitates WebExtnsions by itself. You need to make sure all your add-ons support it first. Tranditional add-ons are not really deprecated yet.
Things that can break traditional add-ons:
Mozilla may replace C++ XPCOM with typesafe Rust code for example
XUL can be faded out as HTML becomes richer.
We all hope Firefox evolve in a way that makes advanced customization always possible. Firefox is now effectively the only modern graphical Web browser that can be used in various unexpected interesting ways. We do not want to lose that ability. But it does not mean that old add-ons will not require updates.
I don’t agree, so far everything I’ve ever seen in an(y) add-on can/could be made restartless; some things would require more work than others of course. Do you have any specific examples of what can’t be made restartless?
Sometimes alternatives are not feasible or well known for:
Binary components (actually needed by very few things, though porting is not necessarily easy even in “possible” cases)
Overriding some locale strings in the browser UI (I’ve heard this problem once, where DOM changes and bootstrapped locale registrations are not reliably reflected)
This includes things technically possible in bootstrapped extensions that do not work as intended in practice.
Possibly in some of the failed cases there might be workarounds that is not well known. Reading a lot of mozilla-central source code might also help.
In short: These are exceptions. Anything typical of an “add-on” can be made restartless. Correct me if I’m wrong.