Alright. In that case, I'd have an object obj_tiler holding the tile's sprite. Ideally, that sprite should have its origin on the top-left to make things easier for you. To get the amount by which you stretched an object in the editor, jsut use the built-in image_xscale and image_yscale. Now you just need to calculate how many tiles fit in there but if used the tile as a sprite, the dimensions should match, so an image_xscale of 5 would mean that 5 tiles fit across.
I can't quite recall how tile-placement in GM 1.4 worked but if possible, instead of having that object placing sprites down, it should write directly to the tile layer, but I think that got introduced with GMS 2. The point is, that you don't want to have the resulting tiles to be any different than the others.
Note, however: You won't see the effect of this in the editor, this only works at runtime. Also, you should make sure to always have your object snap to the grid programmatically so that your tiles line up. Lastly, it might not be saving you much time, as you would either need a separate object for each tile (or have an instance script that switches the tile before it runs) and then there's the issue of instance order which means that you have to make sure that those tile-fills happen in order or a big "grass" might happen after individual "house" fills, essentially overriding them.