The question we actually get
A client does not ask for the Block Bindings API. They ask why the editor feels clumsy, or why a price, a phone number, and a team list are buried in a way only we can change. Under that is a real choice: keep the content in WordPress fields, or keep pretending the page builder is a database.
WordPress can bind a single custom field to a paragraph, heading, image, or button. That has been the useful part since editable bindings landed in WordPress 6.7. It is a good fit for a flat value. It is not a field-group builder. Core still does not give you repeaters, conditional fields, or a relationship picker. If you register the meta yourself, you also own the panel that edits it, unless you are willing to show a client the old custom fields table. We are not.
What we use bindings for
On a brochure site, bindings are enough more often than the plugin aisle suggests. A hero line, an office address, one featured image, a button label. Those are single values. The template reads them. The editor changes them in the canvas. We do not add a custom-fields plugin just so a phone number can live in post meta.
This is also the part that used to be a PHP template. The markup can live in a block template now. Bindings replaced that layer. They did not replace the admin screen where a person builds a structured entry.
Where we still install ACF
We still use Advanced Custom Fields when a client edits the content themselves and the shape is not flat.
A team page with a name, a role, a photo, and a short bio, repeated. A project record that points at a related service. A field that should only appear when a toggle is on. An options screen for the details that are not a post. That is ACF's job, and it is still the one we can hand to another developer without a tour of our private plugins.
ACF 6.8.1 added an opt-in datastore that saves field values through the block editor's own save flow, including revisions and autosave, on WordPress 6.7 or newer. We turn that on when the site is already on a current WordPress and the editors live in Gutenberg. We do not turn it on as a slogan. It is a setting, and it wants each field allowed into the editor UI before bindings show it. Live preview of a bound heading is nice. It does not make a repeater optional.
What we stopped doing
We stopped reaching for a headless React front end because the fields felt awkward. Headless is a different decision, about the site's public shape, not about whether an editor can add a third office. We also stopped writing one-off metaboxes for every new client field. They work, and six months later nobody wants to touch them.
If the content is really an application — approvals, invoices, roles, a state that has to be right — we say so and we build that in Laravel. A field group is the wrong place to hide a workflow. The posts on this site about headless WordPress and about React with Laravel are that conversation. This one is smaller. It is only about who edits structured content inside WordPress.
How we choose on a call
Three questions are usually enough.
Is each value a single field a writer would type once? Use native bindings and skip the plugin.
Will they add rows, relate one post to another, or hide fields based on a choice? Use ACF, and keep the field groups boring and named in their language.
Is the "content" actually a process with permissions and side effects? Leave WordPress for that part. Do not grow a plugin into a private product by accident.
We would rather explain that in the first conversation than migrate them off a clever setup a year later. The editor has to make sense to the person who updates the site on a Tuesday in Lalitpur, or in their own office, without us on the call.