I use that too. I'm sometimes concerned with the effects on performances. I did a quick search.
And found a discussion where Marc Edwards from Bjango says a few things. As this person extensively test these things, I totally trust is jugement. here's the quote:
“Font smoothing on large amounts of text requires more CPU”
Are you talking about sub-pixel antialiasing (-webkit-font-smoothing: subpixel-antialiased;) or standard antialiasing (-webkit-font-smoothing: antialiased;)? Sub-pixel antialiasing requires more CPU than standard antialiasing.
Sub-pixel antialiasing is not possible in a lot of situations:
• iOS doesn't use sub-pixel antialiasing anywhere, because the display orientation changes, and the sub-pixel order and orientation changes with it. That breaks the trick to gain extra resolution.
• Sub-pixel antialiasing typically requires an opaque background to be composited on.
• Sub-pixel antialiasing is less important on high DPI displays.
Further discussion: iOS and Android don't have sub-pixel antialiased type. Microsoft's Surface doesn't seem to either (I haven't seen any screenshots of Windows 8's Metro UI with it). So the entire future of mainstream computing is going to be high DPI, but possibly not contain sub-pixel antialiased type.
If you're grumpy about things not being sub-pixel antialiased, the future is looking pretty bleak.
My advice: Move on.
This battle has been fought and won. Faster performance and devices that can be used sideways and upside down trump slightly better text rendering.
I'm not sure of the performance hit for standard vs sub-pixel antialiasing, but I'd assume it'd be roughly 3×, as there's three channels of rendering an compositing verses one. I'd love to hear from a type-rendering engineer on the topic though.
Discussion from here: http://branch.com/b/please-stop-fixing-font-smoothing
And a Bjango article on sub pixel rendering: