The choice between a page builder and the block editor is usually made on how the editing feels, and paid for later in page weight, lock-in and update risk. Both are legitimate; the trade is worth understanding before a site is built on one.
What a page builder actually gives you
Visual editing with immediate feedback, a large library of pre-made sections, and layout control without touching CSS.
For someone building a site without a developer, that is real value and the reason builders are popular. The alternative is not "write code". It is accepting the layouts your theme provides.
What it costs on the front end
Builders generate markup generically, because they have to work for any layout. That produces more nested elements than hand-written markup, plus the builder's own CSS and JavaScript on every page, including pages that use none of its features.
The result is a heavier page, and page weight is the thing visitors experience directly. A builder page can carry several hundred kilobytes before your content.
Some builders now load assets only where used. Check whether yours does, because it is the difference between a modest cost and a permanent one. How to Speed Up a Website in the Right Order walks through where this sits among the other costs.
The lock-in is the larger issue
Builder content is stored as the builder's own markup or shortcodes inside the post.
Deactivate the builder and those pages do not revert to plain content. They show raw markup or empty shortcodes. So the builder is not a tool you used; it is a dependency of your content.
That matters in three situations: the builder is abandoned, its licence lapses, or you want to change theme and the new one does not work with it. Each is survivable and each means rebuilding pages by hand.
The block editor stores content as block markup in the post, which degrades to readable HTML if the editor changes. That is a meaningful difference in how recoverable your content is.
Updates are riskier with a builder
A builder sits between WordPress and your theme, and a major WordPress or theme update can break that relationship.
Practically: never update a builder-based site without testing on staging first, and expect the builder and theme to need updating together. Sites running old WordPress versions are frequently doing so because a builder update broke something once. For making the copy, see How to Set Up a WordPress Staging Site.
Hosting implications
Builders are heavier in the admin as well as on the front end. Editing a page loads a full editing environment, which is why builder sites feel slow to work on, and admin pages are never cached, so that cost is paid every time. See How to Speed Up a Slow WordPress Admin.
They also store more per page, which shows up in database size and backup times rather than anywhere visible.
None of that is disqualifying. It does mean a builder site needs more headroom than the same content would otherwise.
When a builder is the right answer
When the person maintaining the site is not technical and needs to change layouts, not just text.
When the design requires arrangements the theme cannot express, and hiring a developer for each change is not realistic.
When the site is marketing-led and will be restructured often. The speed of iteration is worth the weight.
When it is not
When the site is mostly articles. A blog does not need per-page layout control, and the block editor handles content pages perfectly well.
When performance is the priority: a shop, or a site where visitors arrive on mobile connections.
When somebody technical maintains it. A well-chosen theme plus a child theme gives more control with less weight. How to Create a WordPress Child Theme walks through that route.
Do not run two
Sites accumulate builders: one from the original build, one from a theme, one somebody tried.
Each loads its assets, and the pages built with the abandoned one still depend on it. Pick one and remove the others, after checking which pages were built with each, because deactivating the wrong one produces pages full of shortcode text.
If you decide to move away
Do it page by page rather than all at once, starting with the pages that matter most.
Keep the builder installed until every page is converted, because deactivating it early breaks the ones you have not reached. Then remove it and check the front end thoroughly, leftover shortcodes appear in odd places, particularly in widgets and footers.
Take a backup first. This is content editing at scale and there is no undo. How to Restore a WordPress Site from Backup goes into having one.
Most snippets people are handed for either approach are the same two functions underneath: Understanding WordPress Hooks: Actions and Filters makes them readable.
Consider what happens when the tool is abandoned
Content built with a page builder is stored in a form that only that builder understands, so removing it leaves markup nobody can edit. That is the cost to weigh rather than the feature list. Before committing a whole site to one, check what the content looks like with the plugin deactivated on a copy. Where the answer is unusable, the site is tied to that plugin for as long as it exists, and its future is somebody else's decision. The same question is worth asking of the block editor, which has a different answer.