The "reusable for free" aspect is about building ecosystems. Abstractions that can be freely integrated with have low barriers to entry to existing complementary systems being updated to integrate with them, or with new systems evolving to wrap them or work in terms of them.

This (plus the fact that blockchain smart contracts are generally limited in size) has the effect of commoditizing much of any given design, instead of keeping it solely in the hands of whoever made it. Things don't remain proprietary; people build their own versions of each contract that are "compatible" per whatever ABI the ecosystem was relying on, and then the ecosystem generalizes its integrations to include those de-facto-ABI compatible systems as well.

And this makes the path from the development of a new experimental + proprietary + closed-world system that requires direct interaction through its own first-party frontend, through to what investment bankers would call "financialization" of the abstraction that system defines as a general-purpose category of financial instrument, very short on blockchains.

This means that in the modern day, there's often far more promise in how financialized a given system is likely to get, when that system starts off as a set of blockchain smart contracts, than when that system starts off as a proprietary brick-and-mortar financial vendor's firm-internal non-market-tradable security.

Meanwhile, the brick-and-mortar fi-tech firm to get their security financialized, they have to convince brick-and-mortar exchanges to carry it for trading; and then other vendors have to come along and copy that success (usually with all the same exchange-side friction + backroom dealings required); and then someone further has to come along and define an abstraction into existence for those live instruments to be reframed in terms of; and everyone has to faff about redoing how their systems work so that those instruments actually fit the abstraction, since the abstraction will be what financial regulations for the financialized security will be written in terms of, and so their own original versions of the security may end up legally non-compliant. And that whole process takes ages — especially if the fi-tech companies push back on the abstraction standard, insisting that their version should be permitted as a MAY option or grandfathered in somehow.

We mostly agree on your points. As I said, the FOSS aspects (which you describe well) are of interest to "undercapitalized startups, amateur financial services, and hackers interested in innovation in this area."

I think my additional points are essential, however: Consumers (and the public) are not interested in rapid development of financial instruments, they are interested in integrity and availability. To them, 'rapid' is a negative. And status quo powers in the financial industry, the banks, are not interested for other reasons too.

Maybe the best thing to develop is a way to make blockchain financial instruments have integrity and availability to match the existing financial system. The integrity and availability are awful, with a high frequency of scams, arguably enabled by the 'rapid' development aspects. If integrity and availability could be integrated into the abstractions, there might be a lot more interest.