I've never liked the comparison of Flux to functional reactive programming. It's really just good ol' object-oriented design. Actions are akin to the Command pattern and the Dispatcher feels like a Mediator. Passing callbacks instead of objects and making a mostly directed graph does not yield FRP.
Since Postgres added a JSON type and Docker made running it simple in development, I haven't had a need for anything else. Call me old school, but I prefer starting with a relational database and changing when it's no longer appropriate.
I agree that it is important that you keep your application small. However, using the application cache like the author suggests means that you will never have to download the specified content, like jQuery, again. Additionally, since you have 5MB of storage, I really don't think the 31KB of jQuery really matters.
I agree that client-side rendering is not optimal, but for different reasons. This isn't 2006 anymore, phones are more powerful now. Unless I absolutely have to, I'm not going to care about your Nokia from back in the Stone Age. My problem with client-side rendering is that it chokes on large data-sets. You also have to pay the penalty to download the dynamic content after you download the static content, but this can be mitigated by only updating the content, rather than using AJAX to load it all to begin with. That also kills the author's use of the plug-in that stores AJAX data locally, but that's a separate issue.
My advice:
Use jQuery, jQuery Mobile, and AppCache. When combined, jQuery and jQuery Mobile (including CSS) take up 58KB of space. Oh, and since you're storing it all locally from now on, there's no need to cry about the time (less than 1s on 3g) it takes to download all those fancy JS files.