There's a fundamental misunderstanding here. Source does not predict, it interpolates because it already knows what's going to happen. The client is always so far behind the latest packet it recieved (well, not if the interp is too low) that it does not have to predict the future. E.g. the client got packets from time t and t+1 and is rendering time t+0.5. It doesn't have to guess where everything will be, it can interpolate that it'll be halfway between the positions at 0 and 1. By the time the client gets around to rendering t+1 it should have recieved the packet from t+2. This would be interp_ratio 1, the bare minimum, usually it's even more packets so the guess can be better than "halfway" and account for changing movement speeds.

Yes, it's much less of a problem in games without stuns but you still have to clean up the dead projectiles (more code), generate more salt because the player sees his own projectiles spawning and then disappearing and the teleporting problem still exists. It's not worth the trouble.

No.
If everyone is living in the past and a projectile instantly spawns locally then it has spawned in the past exactly as far behind the present as the player is. Except no one but the player knows about it. Everyone else will see it after the usual delay that ping/transmission time and server processing time adds. If you want everyone to see the same thing then at that time it must appear where it has already traveled to on the shooters side, meaning it has to teleport.

frootloops already answered the technical side but I think I should add something you're missing: These are completely different use cases.
Fighting games have predetermined animations that will always play out the same and fixed framerates.
TF2, or any fps for that matter, has neither. Any movement can be canceled or even reversed at will. That is a fundamental requirement for dodging. In a fighting game you get an input an know what will happen for the next 20 frames. Fps don't get that. Anything could happen in the next frame. Any attempt to predict when which input will happen is doomed to fail.
On top of that no one will have the same framerate. A delay of 3 frames is meaningless when someone could be dropping to 30 fps and someone else might still be at 300 fps. You're not even in sync with the server's fps. So instead you get another problem: You can't use the server's snapshots directly. Your 144 fps are not in sync with the server's 66.6667. You will not get a snapshot for every frame you render and even when you do get one it isn't necessarily from the exact same time that your current frame will be. So you need to guess for possible states between the servers snapshots. Prediction is useless so extrapolating from past snapshots towards the future is a fool's errand and should only be done when there's no other choice because guessing movement will continue as is is at least better than freezing everything. So what do you do? You don't render the latest snapshot, you put your personal time at least one snapshot behind the latest one recieved and interpolate between it and older snapshots.

The end result is that you have to interpolate and you can't predict others' inputs so you might as well use interpolation for that as well. (see first paragraph)

Also something I should've added when you asked about TF2 being deterministic, but thought it would be complicated and unnecessary in this case. Thankfully Taat (#9) reminded me that it is relevant in this case.
TF2 should be deterministic, but isn't in practice because the source engine's physic calculations are fps dependent. Now that isn't good, but it is unavoidable because when your fps fluctuate and aren't in sync with anything sometimes you have to calculate 0.0034782378623425 of the movement per second because that's just what fraction your framerate is and there's only some much precision you have and then the rounding errors add up. This isn't a problem in a server based game because the errors are tiny and the server can assert its authority and bring everyone back on the "right" track (the slightly wrong track it has chosen instead of the other slightly differently wrong tracks everyone else has chosen) by the next snapshot. In a peer-to-peer game that assumes every input has to same result from everyone's perspective however you are fucked. Everyone's game state would drift further and further apart. Even if you try to synchronize regularly there's no way to decide on a "correct" state. Everyone is wrong, just in different ways.

tl;dr
Fighting games and fps are fundamentally different use cases, using netcode made for one in the other would have terrible results.

If the client can only see the entities the server already knows about it can't "predict spawn" its own projectiles either.

They don't add a delay. They do teleporting/warping by simply jumping to the actual position and because the only thing that will be skipped with decent ping are the startup frames they call it good enough.
Note that this is a horrible idea in any game with hitscan weapons. It's not ideal in their case either because you're losing a couple frames worth of reaction time, which was kind of the point of having startup frames instead of the damage starting immediately but there's always drawbacks one way or the other.
The whole selling point of their method is that there is no delay to your actions, making it feel just like a local game and the tradeoff is that if prediction fails (that is part two of their strategy) you get warped to the correct state but as long as prediction is right everything is exactly as it would be in a local game.

Either projectiles spawn instantly locally and teleport for everyone else (GGPO, if prediction fails) or they appear everywhere at the same time at their actual spawn point which means they guy who pressed the button has to wait until everyone knows about the projectiles before they get to see their own projectile (source). You can't have both at the same time.

I suspect that your ping jumping from 18ms to over 300 is neither ideal nor TF2's fault.

With random spread disabled, probably.
The point is anything that involves a random number generator would be a problem since everyone would get different results.

I'd guess they don't want to deal with the mess that that creates. Firstly allowing the client to predict a projectile that may or may not ever be created in case the player dies before it actually happens but doesn't know it yet (the joys of latency) means they have to clean up "dead" projectiles. Projectiles seeming to spawn and then being deleted is also going to create a lot more salt than projectiles always spawning late if your ping is shit.
Secondly if the time of creation is based on what the shooter sees then everyone else is only going to see them after they have already traveled for ping from shooter to server + processing time + ping from server to everyone else. In other words: teleporting projectiles. Would you rather have someone with 900 ping have a suboptimal experience or have the projectiles he shoots suddenly appear in someone's ass without any chance of dodging?

They don't sent state data, they send only inputs, which cuts down a bit on the bandwidth but most importantly peer-to-peer means instead of the client taking the inputs, rendering a frame (with predictions and data from the server for what everyone else does), sending their inputs to the server, the server rendering a frame, then sending the current game state to everyone who then renders the frame again they can instead send the inputs straight to everyone who can then start rendering their frames. That removes about half the latency.
They also don't have any centralized game state so every time a prediction turns out to be wrong they have to instead execute all frames from the point of divergence again with the right inputs without rendering it visually to catch up to the correct state.
Last but not least there is no agreement as such, it is simply expected that everyone will arrive at the same state with the same inputs. That requires that no one deviates accidentally (no RNG allowed) or maliciously (cheating). No idea how they deal with packet loss. Allowing resynchronization by simply sending your own state/position sounds very exploitable.

Doing things you don't like to get things you do like is an experience not necessarily limited to your teenage years.

Then again I found a job I did like to pay for my first pc, I very much recommend that option.

Anyway, that's the end of the line for me. Sorry I didn't do anything but spread despair about the inescapable suffering of TF2 on a laptop but that's just how it goes. I played TF2 on a laptop with a 1.4 GHz single core Celeron from 2004 so I can tell you it could be much worse.

1.6 GHz baseclock sure is a treat huh. At least with only 15W it shouldn't overheat.
Could probably get more out of it if you manage to raise the TDP but laptop BIOS are usually fairly locked down.
Either way that goes beyond the scope of the choke problem.

Oh, shitty laptop suffering. Either way, 100%, you need all the fps you can get. Unless it's overheating, but that would be kind of embarrassing for a laptop that new.

Defragging actually "damages" SSDs, but you do you. They can only sustain a limited number of write cycles and there are no mechnical parts so unlike with an HDD it really does not matter where the data is located. Not that defragging could do anything about that since they lie to the OS about where they put the data anyway. Wouldn't help with fps either, only loading times, but you do you.

Do you want the CPU to outlive you? I guess it's kind of old judging by the fps you're getting but anything not overclocked or otherwise abused should last for 20-30 years.

I'm pretty sure the fps drops cause the choke, not the other way around and I don't think I can do anything about it.
Did you only change the updaterate or cmdrate as well? I doubt it's going to do anything but I'm out of ideas beyond "it's the fps drops".

Yeah, fewer packets mean they're larger. Sort of confirms that the packet size isn't the problem, you're simply getting larger packets after a choke to transmit the missing data.

Well do you get choke when you're near no one and get 100 fps?

Yeah, I don't think you're getting choke because the packets jump to twice the normal size, you're getting packets twice the normal size because half of them are choked back so you get twice the data in the next packet.
Also solved the mystery of why your cmdrate drops: Your fps are dropping below 66. Makes no sense to send multiple packets per frame.

Do you get fps drops when the choke occurs?

Honestly I don't know how to solve your choke problem (not sure if it is solvable) but things are always going to be weird if your fps drop below your rates. Unless you've got a way to get more fps I'd say dropping your rates is actually a good idea for once. Maybe 40 or 33.

Yeah, definitely weird. There doesn't seem to be any reason for it to choke.
I forgot to ask but how high does the choke go?
Also a screenshot of the netgraph when it's choking might help.
If the choke is low I've got a theory that something really dumb might be happening, otherwise it's something complicated, either way the screenshot might help.

What about the next column (k/s), that's still part of it.
And the choke happens exactly when it goes above 1260? Yeah, could be the splitting, could be a coincidence.

And all at the same time?

The default is 1260, not 1200 (it's literally in the quote) and it is not hardcoded. The minimum is 576 Bytes, as is required by IPv4.

It is also utterly irrelevant for your problem. Packets are choked back either when exceeding packet rate or the bandwidth. Neither the size nor the number of packets changes, regardless of how many fragments one packet is split into it is still one packet and won't get larger.

Is this on one specific server or on any server?
How are "in" and "out" looking in the netgraph?

I doubt changing the MTU would fix that, default is 1500 for pretty much everything, unlikely that your router would have it set lower. Also TF2 should start splitting packets at 1260 Bytes (net_maxfragments and net_maxroutable) so that and a combination of other settings is probably what you're choking on.
You just need to figure out which mastercomfig setting is biting you in the ass.
Try net_splitrate 2, net_splitpacket_maxrate 200000 and for the hell of it net_compresspackets_minsize 1024 one after the other (revert the others back to what you used before, should be 1, 50000 and 1260 according to your presets) and see which one helps.