WordPress includes a number of blocks that we don't recommend using, or are not appropriate for posts (post type). See posts-vs-pages for clarification.
The Feast Plugin now lets you optimize the core blocks available for posts, uncluttering the interface and preventing you from using blocks where they don't belong:
We recommend using this along with the Optimize block typography feature.
Non recommended blocks
WordPress has built a number of core WordPress blocks that are designed to replicate page builder functionality. Pagebuilders don't belong on food blogs.
These blocks have been removed:
One thing that wasn't disabled, but I feel strongly should be disabled, is the gallery block. The decision not to disable it is due to the fact that many people have used it and we err strongly on the do-not-break side of updates.
However, we recommend absolutely everyone avoid using the gallery block and use the columns block instead for process shots.
Full Site Editor blocks
There's also a number of too-early, beta-level, experimental blocks designed for the FSE (Full Site Editor) that have been rolled into the block editor.
This is a naiive decision that assumes all sites have the same requirements, and that the average site owner has the time or care to learn about the drawbacks to make an educated decision. 99.999% of site owners don't know or care or have the time to do a deep dive into this.
There's a huge disconnect between what the engineers think is important, and how they've positioned this setup for the average user.
FSE blocks should not be in posts or pages, period.
If you're a Feast customer who cares about long-term maintenance and wants to focus on content, trust us that these should be removed from your view and headspace when writing a post.
Their specific use-case for FSE blocks is for template parts, and they should be left for.
Note that while we don't recommend using these on pages, we haven't disabled them on pages, only posts. This is because most sites have very low numbers of pages (10-20) and if you want to customize or play with these blocks on a few pages that you'll have to more actively maintain, that's your call to make.
We've also disabled many of the embed blocks, which are typically built without good SEO, pagespeed or accessibility in mind. These embed blocks frequently cause pagespeed issues as well as CLS issues.
Instead, any embeds should be manually inserted with a Custom HTML block.
The only thing we've really ever seen needing to be embedded is a YouTube video.
As a general policy, we consider all social media / third party platforms to be hostile against site owners. This means that their business model is literally to keep users on their platform, not on your website, so that they can sell ads on their platform. They profit from taking traffic away from you and will always, always break embeds.
The history of the internet is littered with dead social media platforms (myspace, friendster, Google+, tumblr) that caused massive maintenance/update issues when they went offline. It's also full of "current" platforms (Twitter, Instagram) that actively APIs and interfaces used to display their content on third party sites.
There is also very real risk that your social accounts get hacked or disabled, with absolutely no recourse for you to recover them.
It's our stance that you should never embed social media content into your posts.
Your goal as an ad-supported content site is to keep users engaged and on your site, not send them to third party platforms that are hostile to you.
Blocks that have been inserted and disabled with this featured will still appear on the front-end (live) of the website, but will show an error in the block editor: