Okay Ace, you're mistaking "tile maps", with fast sprite drawing. You may have tons of experience, but I'm hardly an noob with this stuff either. I've been making "tile" based games for over 30 years now, and lots of professional, well known titles for 25 years.
Let me first tell you the problem with what ""GameMaker"" calls tiles. first, they aren't actually tiles. They are sub-textures of any size and shape, and every one has their own UV coordinates. What does this mean? Well, if you draw a a level, then decide to resize your tiles - well you can't, or rather you can't without vast amounts of work. Lets say you have art assets that don't follow the techblog on dynamically scaling tiles - but that's okay, because when you started, you decided you aren't going to scale, but wait... this little section of the game would be SOOO much better if you could just zoom in a little as it was playing. Well too bad, everything is baked directly into the art assets and you can't easily change them.
There are so many things wrong with the current tile system, it's hard to know where to start fixing it, but actually... it needs thrown away and started again. Doing so means you could suddenly change the size of your tilemap from 16x16 to 32x32, and level would just scale - properly. It means you would never have to worry about dynamic scaling of things, because we could do this automatically for you, allowing you to zoom in and out of a level freely, without glitching, but most of all.... it means we can speed the whole rendering of a single depth up to ridiculous proportions using a tilemap shader. This means for a single depth of tiles, we'd draw just 2 triangles (probably), and no matter how much you zoom in/out, it would never slow down. This is something that's impossible with the current system, as the more you show.... the more we have to submit to the graphics card and draw. We can also start doing "free" tile animation, colours per tile, 90 degree rotation and flipping - all for free (or very close to it). it also means you can start adding multiple playfields, again with virtually no slowdown. But only if we throw away what we currently have and start again.
And that's just for what SHOULD be called "tiles".
Does this mean we're going to suddenly stop letting you just place "sprites" in the level? No...of course not. Our plan is to introduce a very lightweight sprite type, but one that is bound by normal sprite rules, not one that stores UV coordinates directly in the project file, making it much simpler to change sprites regardless of size or shape. We can then bundle these using some kind of space aware storage - be that grids or BSPs, and this would allow us to render the very quickly - and in nice batches.
The other advantage of using proper tile maps - where they are regular grids, is that we could now let you collide with them quickly, speeding up world collision systems. Placing pick ups in the world map means you no longer have to try and collide with almost every object in the world, you just check the map cell your on. You could put flags into a grid that match the level, allowing you to deal with doors, locks, traps - all of which would easily map directly into a tile without any vast amounts of effort.
So what do you lose in all this...... Well, you'll no longer be able to pick a random section of a background as an image, you'll need to make that a sprite, but once you've done that, you can add it to the level just as easily as you have before - in fact more so, because the plan is to allow you to add an image/text etc. without the need of creating an object, and GameMaker will manage them for you, making them VERY cheap storage wise.
Out room editor will of course be rewritten from scratch, and it'll be much more in tune with what modern users need/require. Layers, easy painting/filling of tiles and adding of sprites, not to mention user flags and custom triggers and animations - and I certainly don't consider Unity's 2D system a threat in any way to what we're planning.
So please... enough with the dramatics. Like you, we've been doing this long enough to know what you'll probably need, and we WILL be able to add to this in the future if other stuff comes up, but to do so, we need a solid base - and with the current system, we just don't have that. In fact, it sucks so much I'm amazed anyone has managed to keep working with it. The IDE rewrite will update things so that it all works not only as expected - but better.