A "tile" of 15x15 "blocks", is just another way of saying a "room" with an interior "grid" of coordinates. I see zero value in such a thing.
If you're clinging to the idea of rooms, then the room is your basic unit of encapsulation. The whole idea of rooms is based on the concept that local events should pertain to the contents of a room. That's why combat, communication, inventory… all were designed to work on the contents of the room and the npcs/objects within it. At some point, people got it into their heads that they wanted to make things work across multiple (adjacent) rooms, even though that invalidaes the whole concept of a room.
Once you want things to work on things based on their distance away from you, you are in the coordinate world, and you'd be far better off accepting that and designing your systems to work on coordinate distances, rather than pretending rooms do anything useful for you.
From the user's standpoint, you can easily simulate a room interface by "hanging" descriptions onto ranges of coordinates, and displaying "exits" as descriptions of being able to move in a particular direction. If you only perform a "look" when a player moves into a new "description", you get pretty much the same thing as a set of "rooms", at least from the player's perspective. Observant players might notice that some rooms take more than one "north" to cross, but you could lie and say you have sub-positions in larger rooms and they'd be none the wiser.
As for it being a computational nightmare. I can't see how a simple coordinate -> room mapping is more of a "nightmare" than a coordinate -> tile block -> room nested mapping. Unless, maybe, you're running on a C64 and only have 8-bit integers?
I'd just like to point out that in a somewhat related sense, generated room descriptions (and auto-generated areas) have been done before in a similar medium, to great effect. Hunter, In Darkness, by Andrew Plotkin