In GameMaker this is true, but for big 3D engines? No sir.
Sorry, thats just wrong. Large 3D engines (and I've written a few!) don't render QUADs unless they have to. Things like particles are batched into "dynamic" vertex buffers. This means we go through and add a QUADs in world space into the buffer, then when a renderstate changes (blend mode, texture etc.) then the last batch is submitted. This avoids the issue of having to draw 20,000 QUADs. D3D and graphics card DO not like doing this.
I'll say this again, graphics cards WANT to draw 20,000 triangles (well..large numbers of polys). graphics card dev support gets VERY upset if you complain a game is slow, and they discover your drawing 2 or 3 polys at a time.
What your getting confused over is the difference between static and dynamic vertex buffers. Static buffers are ones you create, and then never change. Dynamic buffers are ones you can create each frame, but these tend to be about a third the speed of static ones. But... you ALWAYS batch things if you can, and certainly with particles etc. you HAVE to. Oh...and GameMaker doesn't even use proper Dynamic buffers either...
If you want to see the history of this... you USED to submit individual triangles, back in DX5 and DX6 days. Then we moved onto tri-strips (still DX6 days). When DX7 came out, we had hardware T&L for the 1st time, and at this point, this rule came into effect. To get the best from it, you had to batch render using vertex buffers, and we had to get used to static/dynamic models. Before this, there was ONLY dynamic meshes, because everything was submitted by the CPU a triangle or 2 at a time.
So really... trust me. You DON'T ever want to submit quads if you can possibly avoid it. Some times you can't help it... but a lot of the times you can.
As to draw call speed. it should be faster as the CPU will now not spend AGES making the models over and over again, it just throws it very quickly at D3D and returns. So should be better all round.
EDIT: Arial: Model Loading time is nothing to do with us... it's up to the extension. We won't be changing loading time that much, and to be honest most of it is in Audio setup, and it stalls inside DirectX Sound initialisation, which is again nothing to do with us; it's driver related.