I'd probably model the hotel as an object Hotel, the room as an object Room etc. rather than stacking everything together in a multi-tiered collection. That becomes very verbose very quickly, and as soon as you change the relationships then that change is reflected throughout your code.
Each object then contains references to its components (Hotel contains a list of Rooms etc.). Once you do this I think everything should become a lot clearer. Furthermore your Hotel object understands how to find Rooms, the Room objects understand how to get its attributes and your calling code becomes a lot less verbose, and a lot less dependent on the Hotel/Room implementation. e.g. you can do this:
Hotel hotel = new Hotel();
Set<Room> rooms = hotel.getFreeRooms(RoomType.NON_SMOKING);
and so your objects do the work for you (the client) rather than you navigating the object hierarchy and doing the work yourself.
That's the ultimate goal of OO. As soon as I find myself putting together collections of collections, that's often an indicator that a new object class is required.