Why on earth would the ESEA client and servers not be able to adapt to an official TF2 update within a matter of hours? Sounds like a design issue with the client and you should bother ESEA about that.

mat_shadowstate does nothing.

Why would this be a placebo?

Basically (assuming you have shadows enabled) cl_blobbyshadows 0 renders all player models, weapons, gibs, and health/ammo packs a second time. cl_blobbyshadows 1 does not.

Submitted a pull request: https://github.com/RhapsodySL/perfconfig/pull/23

tl;dr: mat_maxframelatency does nothing, and the engine is already tuned optimally for lowest input latency.

Judging by the name, this controls the maximum number of frames that the cpu is allowed to be ahead of the gpu by. This value is in frames, not seconds, so it's an integer, not a float. There's no difference between 0.2 and 0.9, because they both truncate to 0.

As of 2007, this cvar wasn't hooked up to anything, and there's no reason to believe it is does anything now. I believe it was replaced by mat_frame_sync_enable (cheat, default 1) when multi-threaded rendering was added to Source (mat_queue_mode 2). In short, mat_frame_sync_enable forces the renderer to wait for the previous frame to finish before it starts on the next one.

Either way, frame syncing is designed to reduce input latency at the cost of a few fps. If you had sv_cheats 1 and decided to set mat_frame_sync_enable 0, you *might* have improved fps, but you would instead be getting (potentially large amounts of) input lag.

Edit:

There is absolutely no reason to include mat_framebuffercopyoverlaysize in your config or anywhere else for that matter. All that cvar does is control how large the debug overlay for the framebuffer copy texture is. It has no performance impact unless you have sv_cheats 1 and mat_showframebuffertexture 1, and even then the fps difference would be measured in microseconds. Here's mat_framebuffercopyoverlaysize 256 (look in the top left):
http://steamcommunity.com/sharedfiles/filedetails/?id=460659888

mat_framebuffercopyoverlaysize 1024:
http://steamcommunity.com/sharedfiles/filedetails/?id=460659916

Same thing happens for me, even though the streams I watch only use about 5% of my total downstream bandwidth. Its definitely an infrastructure issue on Twitch's side.

Been thinking about it, plus a plugin or two... looking forward to a free summer for once :P

r_occlusion 0 // disables ambient occlusion. 2% FPS boost

No.

r_occlusion 0 disables the occlusion system, which allows mappers to manually optimize their maps via the visibility system. If you were testing the effect of this cvar on a smaller, older, or simpler map, that's probably why you were losing fps. On any moderately complex map, you will gain fps by having this enabled.

sys_minidumpspewlines 500 // Basically the number of lines saved to a log file from console. No FPS boost but 15% lower FPS variance

Again, way off. This controls how many lines of the console are saved to the minidump created when your game crashes. This has no effect on the fps you get, and the only effect of increasing or decreasing it would be changing the amount of time it takes for your game to crash by a few microseconds.

mat_antialias 0
mat_forceaniso 0

Don't set these to 0. The minimum value of these cvars is 1, and setting them to 0 will just cause a material system reload = breaking mumble overlay/increasing game startup time. Think about it: mat_antialias controls the number of samples taken per pixel on your screen. If you took 0 samples per pixel, your screen would be entirely black :P
Reading directly from the game's code, the same hardcoded minimum exists for mat_forceaniso:

pConfig->m_nForceAnisotropicLevel = max( mat_forceaniso.GetInt(), 1 );

mat_max_worldmesh_vertices 512

Minimum value for this in code is 1024. Additionally, lowering this value increases how many chunks world geometry is broken up into, leading to more draw calls = more cpu usage. No reason to lower this from its initial 65535.

That's all I have for now.

While I also can't think of a way off the top of my head to have the sprites interpolated while being player-specific, perhaps if you were ok with them being team-specific (for MGE, where you still only have 1 player per arena so don't need to worry about different projectile speeds) you might be able to use the material/entitiy that creates the team-specific blocks outside of spawn entrances: http://puu.sh/i4ay4/4b57ee1141.png

Here's assuming the fade distance for those are modifiable.