I think the point is that on Ethereum a new smart contract/DApp can be added to the network without the approval of anyone but the author of the code.

This is not possible on BitShares. And it isn't just a technical difference (AOT-compiled code vs interpreted or JIT-compiled bytecode) but a policy difference. The Graphene toolkit is well-designed for blockchains that choose to not allow arbitrary user-submitted code to be executed on their network. The cost in resources to run any particular logic on their network is explicitly approved by stakeholders for each new piece of logic added to the system rather than generalizing that cost to some sort of "gas" that must be paid per unit of computational resource consumed.

This policy decision comes with trade-offs. On one hand, through explicit approval by stakeholders, the computation costs can be tailored to the specific logic in commercially smart ways. For example, you gain the flexibility to not even charge a fee for certain transactions, e.g. posting comments or voting on Steem. As far as I am aware, that sort of no-fee structure isn't even possible to do with the current Ethereum design (although perhaps it can be approximated if you provide a "deposit" fee in your transaction that is returned to you from the DApp fund pool if your transaction successfully completes without running of gas).

The downside is that requiring explicit approval from a decentralized group of stakeholders to actually realize your code on a live network adds further uncertainty to the success of your business. It definitely tends to weed out any non-serious additions to the code. But by discouraging a lot of small devs from trying to build cool new projects experimenting with high-risk concepts that could turn out to be really big and valuable, that policy might be hurting the platform in the long-run.

Of course, even going beyond the policy difference, technical differences can also account for a lot of the difference in dev involvement in the BitShares and Ethereum communities. C++ is pretty intimidating for the average coder. Making sure your changes don't end up accidentally screwing up other people's code in the BitShares/Steem codebase is also pretty intimidating. It is nice to have a dev environment that sandboxes your code to provide everyone with guarantees that this won't happen, and also allows you to code in a more user-friendly (even if less efficient) language accessible to more developers.

Edit: By the way, I think there might be some potential of adapting the concept of rate-limited free transactions (i.e. your fraction of stake in the system determines your fraction of the dynamic bandwidth available) to the concept of Ethereum gas. In other words, your fraction of the stake in the system determines the fraction of the currently allocated computation resources your transaction is allowed to consume (perhaps with safeguards included in the transaction to not even bother running it, which would avoid consuming from the submitter's daily resource allotment, if the network cannot guarantee some minimum amount of computational resources for computing that transaction). Then you simply inflate the stake like Steem to pay block producers, thus requiring users to continually buy more of the stake to maintain their same resource allotment fraction. This could be a clever way to get around the transaction-fee cognitive burden.