Your idea is possible without needing the seller to run a lightning node. Instead of having the seller create the hodl invoice, you can run a lightning node and create a hodl invoice. This doesn't mean the payment will come to you. Before creating your invoice, get a regular lightning invoice from the seller's ordinary lightning wallet, extract its payment hash, and use that payment hash in your lightning invoice -- which is a hodl invoice. Once that is done, the buyer can safely attempt to pay your hodl invoice, knowing that you can't settle it except by forwarding the payment to the seller -- i.e. by paying the seller's invoice. That action will get you the preimage you need in order to settle the buyer's payment, thus completing the circuit.

My hodlcontracts software is designed to automate some parts of this and make it easy.

Regarding htlc bloating, it is true that lightning node operators sometimes get mad when a payment has a really long htlc because such payments can lock up their liquidity for a long time. However, there are pretty good solutions out there for managing that. It is easy to configure your lightning node not to forward long htlcs, and you can even price them differently by setting up a low-fee node that won't forward long htlcs and a high-fee node that will. Each node's htlc duration limits are part of gossip, so wallets can easily detect if they need to create a long htlc and then seek routes that will forward it.

There are also ways to limit htlc bloating by introducing more messages. For example, a custom routing node can easily delay forwarding long htlcs until it gets a message from the seller saying they are ready to receive the payment. Once they get that message, they can forward the payment and expect instant settlement by the seller, thus avoiding imposing a lengthy lockup period on other routing nodes. People who want such a service could then send long htlcs with low bloat by opening a channel with that custom routing node and sending their payment through that channel. In that case, the only htlc slots that get locked up belong to the custom routing node, who explicitly permits this as a service and therefore (probably) charges a high enough routing fee to compensate for the time value their money loses while locked up.

Everything in the last paragraph is easy to do today with wallets that let users choose their channel counterparties, such as blixt wallet, electrum wallet, and zeus. Most popular LN wallets do not let you to manage your own channels, and thus they cannot take advantage of the above-described technique, but perhaps if such services became popular, the popular wallets would add support for it. In the mean time, you could just recommend better wallets for an optimal experience, but still -- even using a basic wallet with no channel management features -- such payments should work just fine, and if routing nodes get mad that their htlc slots get locked up as a result, they can increase their fees for long htlcs using the tools that are already available.

So don't give up on your idea! It is very possible to do today.