Items could be placed at any pixel location within the bounds of the container. The game used the same X and Y (integer) variables which otherwise denoted the item’s location in the world.

This gave players more degrees of freedom to arrange their inventory as compared to a one-dimensional slot-based system.

The Ultima series was known for its attempts of immersion (in the singleplayer games you are supposed to play yourself), so things like a world simulation were built into it as the games progressed (you want to bake bread - get flour, mix it with water, bake it in an oven, etc).

This spilled over to the UI/UX design - so having a free form inventory meant it felt like you had a backpack.

Except that you don’t have to write any more code. You already have code for objects sitting on the ground in a room.

Interestingly, in UO the ground was a grid based system, you could only drop items into a tile and they would be centered there. So the floating inventory system was different code it would seem than the discrete ground system.

You'll still have to modify that code to apply to containers, versus a a set/array that your language probably already supports

Sure, your language has some kind of lists or arrays or whatever, and you could use one to store an inventory. But the UI designer decided that the player should be able to rearrange items in their inventory, so now you have to store a position for each one. And it has to have a background image, and such. But that’s what a room is! The room itself has a normal array of items and an array of positions, or something similar.

Sure, rooms have a few extra features that containers don’t necessarily require, such as the ability to have exits. But that’s ok, the list of exits can be empty. No problem. Even if you enumerated all of those extra features you might not realize to document that nobody should ever put _actors that can move around on their own_ into a container.