The load problem definitely doesn't jive with my experience, so I'd like to hear about it if it happens again.
I do a lot of Pyret work on a many years-old Acer Aspire Timeline X, and the slowest loads (in powersaver mode) take 25ish seconds. The lab machines my students work on take about 5-10 seconds, their laptops differ widely in (guessing a bit here) the 5-30s range, and many do work on their laptops. Students are somewhat annoyed by the load time, but this is actually not out of the ballpark for how long it takes, say, DrRacket to start (just now it took 5s on my lab machine, ~11s on my piddly laptop). So in our experience it hasn't been prohibitive, but that doesn't mean there aren't classes of machine/browser combinations that screw it up that I don't know about.
I recommend Chrom[e|ium] to my class at Swarthmore (Chromium is installed by default on department machines here), though Safari and modern IE (IE10+) have worked totally fine in practice, too. Firefox has some unfortunate interactions with the way Pyret does stack management that can make it really slow. I do have a few students who stick by Firefox and do all their work in it, despite the slowdown, so it's not unusable for them, but it is annoying.
For some assignments I do imports from Google Drive for black-box support code, and that requires connectivity, so I've gotten some minor complaints from students doing a lot of air travel (for e.g. job and grad school interviews) about that. But my students are used to having some assignments that require access to machines in the department, so it isn't a huge deal. With a Chrome App, or even just upcoming standards like ServiceWorkers, we should start to be able to cache enough/do more in the browser to make this a non-issue, even across tabs closing and browser restarts. There's more we could be doing right now with localStorage to get around this, even, but just haven't done the engineering required. So no fundamental obstacles to a better offline experience for the browser-based editor, "just" substantial engineering work.
The CLI and packaging up Pyret as an installable "binary" (really a JS blob + Node) are works in progress, but having a good CLI repl is an explicit goal.