How to choose between Bean, Boxes and Fieldable Panels Panes? Bean, Boxes and Fieldable Panels Panes all provide similar functionality. I have trouble understanding what exactly the differences between them are.

What are their advantages/disadvantages compared to each other? Are they geared towards different use cases?

I want to use some kind of blocks in Panels to add custom content - content editors also need to be able to add content, in that sense the blocks I need are not pure configuration. But I also use Features...

Edit: I'll add what seem to be the main differences

Boxes


Largest userbase (~ 11500)
Treats blocks as configuration (i.e. the content ends up in your features)
Modules offering integration


Beans


Has recently become popular, ~1000 installs
Treats blocks as content, but allows exportability of their configuration via machine name (e.g. via Bean Panels)
Modules offering integration


Fieldable Panels Panes


Smallest userbase (~ 400)
From the author of Panels/Views/etc.
Panes cannot be used as regular blocks in theme regions like beans or boxes (I assume)
I wonder what the advantages over Bean mentioned here are ("offers additional features that makes it easier to empower content admins to lay out certain pages")
It's perfectly possible to make a D7 site without blocks if you can live without dashboard. 
Our new - content driven - site is being built on panels with workbench as a suitable (for us) alternative to dashboard. Arjan appears to already understand this. 

On to the alternatives.
Read Your site should be full of beans.
The problem with boxes is the danger regarding overwriting existing content when using features. But read Fabian Franz's comment in the same article. Beans has many options. I'm not comfortable regarding management, scalability and performance. Hardcore developers that are fluent with panels use Fieldable Panels Panes. Fieldable Panels Panes lack documentation and examples.
What should get everyones focus and effort for D8 is the wscci-initiative. It allows for REST-calls, including for example DELETE. This could permanently tackle the problem of overwriting site builder configuration on code rollouts.