Scene graph organization is guided by the various consumers of the scene - see answer to "Scene Graph as Object Container?" Fundamentally, the scene graph associates objects such that they share some logic, physics, position, and/or render state.
So concerning organization-by-type, except for very simple games it would be a mistake to treat the scene graph as a kind of folder structure. At no time would one want to hide all the walls or rotate all the doors around a common point, so the containing object would serve no purpose other than to group its children and isn't taking advantage of the scene graph. It would be better to use a tag or code level data structure for behaviors like "open all doors" or "remove all potions."
Proximity takes advantage of the scene graph logic. For example, you could break your scene up into chunks so that you can turn distant chunks' visibility or logic off when they're too far away to have an affect on game play. So most larger games, on the surface, will appear to be organized by proximity.
However, a further confounding factor is that the scene graph is mutable. Consider a game where the player can drive a car. In terms of the scene graph, the player's avatar becomes a child of the car entity - we'd like to just move the car and not have write code to adjust the avatar ourselves. We would then feed the player's controller input to its immediate child, which would filter down un-handled actions to its children, and so on.
Before
PlayerController
Avatar
Car
PlayerController.Left -> Avatar.WalkLeft
After
PlayerController
Car
Avatar
PlayerController.Left -> Car.TurnLeft -> Avatar.LookLeft