A Paper server with TPS you can explain

The lineage is CraftBukkit, Spigot and Paper. Because Paper preserves the Bukkit and Spigot API, a plugin jar compiled for Spigot loads with no recompiling. That is why the installed base of EssentialsX, LuckPerms, Vault and WorldGuard keeps working after the switch.

What Paper adds is implementation, not a new incompatible API: rewritten chunks, light engine, entity tracking, hoppers. None of that makes the tick parallel, the gain comes from each tick costing less. Swapping the jar buys a real but bounded improvement, and the rest depends on configuration and on which plugins you agree to load.

TPS is capped at 20. A server spending 45 milliseconds per tick reads 20.0 and looks healthy, when it has 5 milliseconds of headroom. One explosion or somebody exploring fresh terrain is enough to go past 50 and the number collapses. Whoever watches TPS alone finds out after the players do.

Look at the distribution, not the average. A low median with a high 95th percentile points to a periodic spike, and the usual suspect is autosave, a scheduled task or terrain generation. A high average with a narrow distribution points to constant load, almost always entities, hoppers or code running on every movement event.

It is also worth separating tick lag from network lag. If mspt is comfortable and the player still feels delay, no yml key will fix it.

From Paper 1.19 onward the configuration was split into two files inside the config folder: paper-global.yml, with what applies to the whole server, and paper-world-defaults.yml, with the world defaults. Each world can still override whatever it wants in its own paper-world.yml. Old tutorials still tell you to edit a paper.yml at the root, which no longer exists in those versions.

In the global file almost everything stays at default, and what justifies an edit is proxy integration, the packet limiter and chunk loading. The gains people are after live in the world file: despawn ranges, mobs per player, collision, hoppers and the redstone implementation.

Per-world overriding is the most underused feature here. A mining world handles aggressive despawn and short simulation without anyone complaining, while the main survival stays conservative. Applying the same aggressive configuration to every world turns optimisation into a support ticket.

That optimised file going around the forums applies dozens of changes at once. It works on the server of whoever wrote it. On yours, two or three of those keys will break something, and you will have no way of knowing which because you pasted it all together.

The damage is predictable. A very short despawn plus a reduced spawn range produces the classic complaint that no mobs spawn to farm. An activation range set too low makes mobs stop walking and the farm stop with them. Stripping the AI from spawner mobs kills mechanics that depend on movement. A high merge radius changes how drops group on the ground. And switching the redstone implementation changes the update order of the wires, enough for a timing sensitive contraption to behave differently.

Accept as well that a good part of the gain is in no yml at all. The heavy plugin is almost never the one with the biggest jar, it is the one querying a database synchronously on every event, sweeping entities in a repeating task or forcing chunk loading outside the async path.