Actually it is, especially when you're working with a team of developers.

Imagine that your designer puts together a design system built on a soft grid. The rules in the design system are what ensure consistency across the site.

If you have a team of developers, sooner or later you'll manage a junior dev who interprets the design as a pixel perfect layout, and starts defining widths on elements per their own personal interpretation. Maybe they eyeball it, maybe they measure it, maybe they measure it but don't include the border.

You can catch such things through training and code review, but it puts the burden of managing design consistency on a senior engineer. Starting out with a constrained system is one easy way to ensure consistency of design across large projects.

As an example, it means you’ll never be off by a pixel here and two pixels there. You’ll be off by, say, five pixels or ten pixels instead. Your mistakes will be obvious and easy to fix.

It’s the difference between working with Lego and working with ordinary hunks of smooth plastic.

That's the nature of any higher-level language: you reduce flexibility and gain ease of use for particular use cases.

E.g., With Ruby and Python and Java you lose a lot of the flexibility that pure C gives you. You can't directly manage memory directly any more, for example. Is that a bad thing? Not for most people.

Note also that one of the major goals of an operating system is to limit flexibility. The first thing an OS does on starting is to lock a bunch of functionality away from any other code. Similarly, virtualization and containerization are mainly about removing capability.

In some situations, choice reduction can come from abstracting them away. Then, by definition it's a good thing. Assembler v C. Of course, if the abstraction is inadequate (leaky), then you haven't really abstracted anything away.