Early systems that saved only on disconnect tended to also save periodically while the player was active. In those systems, typically MUDs (Multi-User Dungeons), the character was maintained in memory until they were periodically dumped to a file.
This meant that if a user disconnected without "camping", they usually found themselves several rooms away and missing a bunch of loot, XP, etc, from the last time they saved. In that regards, it behaved a lot like how console RPGs play today (you have to save your game without turning off the console, or you lose everything since the last time you saved).
The system worked for its intended purpose, because characters could not interact with each other, except possibly by way of a "mail" system where they could send messages and items to each other. The chance of losing items and progressed tended to be pretty significant, but only affected one character at a time in most cases.
The worldsave feature came about because characters were eventually able to directly interact with each other, so all of the characters playing had to be in a consistent state, or item duplication and deletion could occur. This wasn't a problem in the MUD scenario, because it was difficult to abuse the system in a way that resulted in item or currency duplication, but it was incredibly easy to do in early MMO MUDs. Player A gives player B an item, player B saves and player A disconnects without saving. Instant duplication.
Worldsave is not a performance benefit, but designed to prevent cheating. I recall playing on systems where the worldsave event was literally announced in advance, and often hung the entire system for a minute while the server updated all of its files. While this prevented cheating, it was not very convenient for the users of these systems.
That leads us to the current state of affairs. Today, we don't use worldsave type functions. We use databases. This allows us to make sure that duplication and deletion is minimized as much as possible. The characters exist as records in a database, and each transaction between players is a literal database transaction; either the action is fully committed or it will be rolled back.
Barring unusual bugs in the system, you get the benefits of saving individual character files (quick save times) and the benefits of worldsaves (no cheating), without the drawbacks of either (losing significant progress and item duplication).
When designing a modern MMO, you would want to create stored procedures in a database, and use those procedures to perform transactions. For example, when doing a trade between two players, it might look like this:
start transaction;
insert into inventory values(playerid=111, itemid=222, quantity=1);
delete from inventory where playerid=111 and itemid=444;
insert into inventory values(playerid=333, itemid=444, quantity=1);
delete from inventory where playerid=333 and itemid=222;
commit;
(Note: this may look like SQL, but probably isn't, and is only meant to be an example).
In this way, if there's a crash before the commit, the system rolls back to a state where player 111 and player 333 still have the original items, while after the commit, the trade is completed. There's no opportunity for duplication, because the characters are saved at the same time, as guaranteed by the database.