If you're storing a picture of the tile on every object, when most of them are similar, you could just give it a stamp and retrieve the image corresponding to that stamp when drawing.

But memory-wise it would get ridiculous if you had massive maps all loaded at once, which could he solved by loading tiles as you need them, but would that slow things down?

Assuming there is no per-tile data, yes.

I've been playing with various tile engine designs, and I've settled on Tiles being simple immutable value objects, just an index into a Tileset, which both holds the TileTexture and maps names to Tile instances (the TileTexture is basically a spritesheet that the tile is indexing).  A Tile can also contain color information if I want to override the color on any specific tile, but otherwise it's a simple lightweight affair.  

All the actual opengl drawing commands are issued by a DisplayLayer, which contains a Tileset and a list of tiles.  This keeps the drawing code in one place, which makes it easier to optimize.  DisplayLayers can also contribute other things like a default color and blend mode, which makes stuff like moving a semi-transparent cursor around a simple matter of making a UI display layer I can enable and disable.

Tiles are strictly graphical in purpose for me, they don't contain game information, so I maintain separate 2d arrays for the game state, and just define a function to render a region of that gamestate array onto a tile display.