[martyfmelb]

Increased UI testing surface, tracing responsibility when things go wrong, and inserting a new decision for every single metric any FE developer ever writes.

- The more obscure combinations of viewing options you support, the more likely you'll miss some weird combination in your VRT or manual testing until an actual user in production finds it for you.

- But maybe your manual tester or VRT has excellent coverage. Still, it got more expensive. Supporting just one more text zoom level doubles your VRT expense. Your team has finite QA resources and VRT compute. Scope/quality/cost/time of something, somewhere, had to be dropped. Generally, is it worth it?

- If you are supporting REM and your designers don't distinguish between REM and PX, you have created new states that designers haven't planned for. You introduced a new cross-cutting source of design bugs, but if your designers didn't ask for this feature, they can't stem the flow of bugs!

- If you are supporting REM without coding guidelines to recommend what should be REM vs. what should be PX -- sans a hero dev who sees the impending mess and writes those docs for you -- you will get a chaotic and inconsistent mix of REMs and PX in your code.