Not really a Game Maker exclusive concept. Truth is, tile collision is MUCH faster and way more efficient. Well, if you do it right at least. That said, since you mentioned it would need a custom movement code to work in GM, if done wrong it can be slower and less efficient.
I'm not sure how GM handles 'sprite' collisions exactly, but under typical circumstances you'd check the bounding box against every other active sprite, for each active sprite. If one of them intersects, do a more refined polygonal based collision check (if GM even does that, I don't know, I don't use it, but this is what I do). Then if they intersect we have a collision to process.
It can be handy for simple non-grid level layouts. I stress simple, because using this you want to minimize how much of these objects you use. The problem here is that the more that you use, the more checks it is forced to make, and the slower it gets. Very bad. A fighter game like Smash Bros, simple small one 'room' stages, would use something like this, especially if it has no 'grid' design to their stages and many many slope styles and angles that are irregular. Castlevania though? Eh. I wouldn't recommend it. You wouldn't need any of the advantages that it offers anyway.
With a tile based system, you don't have to check EVERY tile in existence. You can localize your collision checks to tiles within the object's bounding box only. Not only that, you can (and seemingly have to) code exactly how the check is performed, and how to handle it. It gives you the ability to really refine things.
Bottom Line: It has the potential to be much more efficient, if done right.