plugin system: actually, fte does have a plugin system already. its just not used for all that much right now. you CAN make plugins for new model or package formats, video decoders or encoders, etc, as well as various plugin-based UIs, but plugins tend to have additional maintainence costs (for both developing and for users - a proper installer helps for users, but also kinda defeats the point).
replication: it'd be nice to improbe this. sendentity is really quite awkward to use, it'd definitely be nice to be able to specify some list of fields that should be replicated and for it to just happen, but also quite fiddly. in the mean time, the deltalisten builtin can be used to replicate ssqc ents the easy way, but you're limited by the fields and precision of said fields.
you could also make a qc-based library to handle replication a little more automatically, but the whole SendFlags thing is still going to be inefficient.
csqc: if you're using stats and assuming that those stats apply to ALL players, then that's kinda your problem, not an engine limitation. stats are specific to the local player entity. if you want stuff about other players then use fields or even userinfo.
thisplayer = find(world, entnum, player_localentnum);
try that if you just want the local player. which can be world if nothing is known about it. obviously, 'self' is too messy when its changed randomly depending on which entity you're referring to at the time and has nothing to do with the local player.
animations: fte's csqc already has .baseframe .basebone etc if you want separate control over the upper+lower(base) part of a player. its more limited than the skeletal objects system of course, but it should still work to allow you to animate things separately with a single entity.
it'd be nice to add basebone+baseframe to ssqc too, but modifying protocols for something that I'm not sure would be used is not something I enjoy the sound of. either way, csqc animating things is the only way to solve the more annoying issues.
also, qc-based libraries would be handy here.
native physics engine: I did start to make a plugin to use bullet instead of ode, which was meant to make things more robust. I kinda got bored when it showed some of the same issues that ODE had, namely that its still possible for things to pass through walls.
writing my own physics engine isn't something I wish to subject myself to. I'm scared enough by FPU precision issues as it is.
ui libs: I've never heard of librocket, and I personally hate anything to do with the web. that said, I have been working on a libcef plugin which kinda does the same sort of thing. however its basically a complete web browser, and has annoying extra latencies. should still be usable for menus though.
alternatively, you can find my menusys library thing on fte's svn, in the quakec subdir. if I were to release a more friendly ui, this is what it would use for menus. it should be fairly straight forward once you get used to it, just try to avoid looking too deeply at first because the code is quite... err... distinct. yeah, lets go with distinct. certainly doesn't look much like anyone else's qc.
blender: gah. I've not looked in to it, but I would imagine that it would be a horrible overcomplicated format. importing .obj into a realtime-lit otherwise-empty world defined with just an .ent file is a much more realistic proposition. maybe it'll be usable one day, maybe it won't. in the mean time, try csaddon's terrain+brush editor.
gi: I doubt I'd be able to get it efficient enough to be usable, plus rewriting the renderer to cope with it is not something I currently feel comfortable with, as I'd probably get up before its even half complete.
shaders: you can remap shaders with some r_remapshader console command (the underlaying feature was required for q3 compat). this replaces the shader but not the material, so replacement shaders that still use $diffuse will still inherit the appropriate textures if you want to (ab)use it for an entire section of the map or whatever.
commands: in config files (including those saved with cfg_save_all set) will have nice groupings for the various cvars. otherwise you'll probably want to use either apropos if you want to search for some keyword in the name/descriptions, or just enter some grouping prefix (like in_ or r_ or sv_ and so on) and then use the auto-completion lists that the engine tries to suggest.
maybe stuff will improve with time, maybe improving it will break other things, or maybe I'll try to improve stuff, fail, give up, and take on easier stuff leaving those features never working.
time and motivation... gah.