WebGL can't actually render text like the canvas2D renderer can. So, to render text in WebGL mode, this happens:
1. Each text object creates its own canvas2D surface
2. Text is drawn to canvas2D
3. The canvas2D is copied to a WebGL texture
4. The WebGL renderer draws the texture in place of the Text object
If the text changes, steps 2 and 3 are done again. If the text doesn't change, it merely has a static WebGL texture to draw, which is about as fast as rendering a single sprite.
However there are two things which get really bad performance out of this, which I think you've already discovered:
1) If you create & destroy text objects every tick, it will be creating a canvas2D surface and WebGL texture every tick. The browser should garbage collect these to prevent it running out of RAM, but I guess it's not a well tested part of browsers because they don't expect anyone to be doing that! Also C2 is smart enough not to create a canvas or texture if the text object is not drawn, so you will only get bad performance if you create lots of on-screen text objects; off-screen ones should not ever create anything.
2) If you change the content of a text object every tick, it has to keep re-rendering then copying to a texture. Note this is only required in the WebGL renderer: the canvas2D renderer can just draw the text directly. For small objects this is fine, but when debugging games some people use window-size text objects printing loads of data. This can be pretty slow on some systems. It might be better to try using lots of separate text objects. For example, if a single text object is set every tick to "Object count: " & objectcount, then C2 is smart enough to only re-render the WebGL texture when the object count changes. If that's a single line in a giant text object that's continually changing, it will include that line in the re-rendering every tick.
Point 1 should be an easy fix (don't create and destroy lots of text!) and point 2 should not affect production releases (since you would generally only use large, constantly changing text objects for debugging). Very few people have noticed it really works like this, so I think for 99% of projects it's working perfectly well. But for certain edge cases it does help to be aware how text rendering in WebGL works.