Besides having access to JIT, being multiprocess, getting the backward/forward swipe for free and finally having a decent way to estimate progress, WKWebView is actually worse than UIWebView and less customizable. UiWebView, as slow as it is permits you to do stuff like saving pages for offline viewing, ad blocking, cookie control and so on.
If they use WKWebView I'm not even sure they can implement the features of a plain old browser, never mind include addons/extensions.
Some of your concerns are true, others are not. Cache and cookie control is currently impossible with WKWebView. However you can retrieve the contents of the page and load them just as you can with UIWebView, as well as ad block using the new user scripts features, which are a much better framework than what was available before.
Can JS really block requests to a server or is it more ad hiding than blocking? I suppose WKUserScriptInjectionTimeAtDocomentStart could be used to inject something that will e.g remove ad-related DOM nodes, although this is more theoretical than a reality I guess.
UIWebView can drop connections based on URL matches and also content analysis OTOH, and that's a pretty well understood way of doing things.
One more plus for WkWebView that I forgot - the history list and moving backwards/forwards in it. I agree it has some really nice pluses, but at least for my use cases (and the use cases I would be interested to see implemented in iFirefox) it doesn't seem to be the right choice.
I think it's also important to remember that this is a very much 0.5 release, very much not ready for prime time. In a year or so, likely the state of WKWebView will improve greatly.
If they use WKWebView I'm not even sure they can implement the features of a plain old browser, never mind include addons/extensions.