A way to, I would think, handle that while still having a good control over it, would be that maybe rooms acts like container that you defined partially(sort of):
When you create the room, all the objects inside will be created at the relative positions to the room (something I actually tried, and failed to, do with events combined with layouts, maybe did not tried enough, or did not understand the purpose of Json objects strings.)
You could pick objects that are related to the room object instance you want
When the room is destroyed, or that an action "clear room" triggers, all related objects are destroyed (from my understanding of C2, if an object that was not included in the layout view is destroyed while there is no more instances of it, its texture will be unloaded from the memory)
When an object is destroyed however, the room associated with it will not be (saying that because I compared them to containers, and I know people would have brought that up..)
So the room could basically be:
A rectangle (or other shape but for now, lets not be to complex) that when a action "load room" is triggered, would create instances of ennemies, grounds, tilemaps or other things, relative to a predefined status (like if the room was done in a layout like view, each instance saved, then created at runtime relative to the room position and potentially size, but position would be fine).
One current workaround for that would be a tilebackground room object, and a careful event creation of the objects with a carefully crafted function, the specificity of the Room object I defined would help a lot in that (as the create room function, and easier handling of positions and data via an edit room like layout view would make it really easy).
The camera shall not be controlled by bounding to the current view by defaut I would think, but since you could always do a manual camera handling if you wanted, it is not that big of a deal..