The two issues are separate -- they didn't change the extensions system to make Firefox fast, they changed the extensions system because the old extensions system was a security nightmare.
It does actually play into performance, too. The new multiprocess architecture requires that extensions get updated to be compatible with it. It is possible to achieve that in the old extension API, but every single extension author would have to do that, which is just not ever going to happen.
Otherwise, if you install a multiprocess-incompatible extension, Firefox will essentially fall back into single-process whenever that extension does something. So, then a good portion of the extensions on AMO would come with severe, for the user inexplicable performance problems.
Mozilla would have just not rolled that out without knowing that the switch to WebExtensions will clean that all up.
Well, and then besides that there's also the points that 1) the old extension API is quite complex, so it's comparatively hard for extension authors to write an extension, especially also qualitatively good extension, 2) the old extension API was really unstable, basically whenever Mozilla changed something about Firefox, some extensions broke, and 3) with the new extension API being based on Chrome's extension API, it becomes often trivial to port Chrome extensions to Firefox, making it much more likely that Firefox will continue to have extensions even if Chrome continues to eat up market share.