This isn't a frontend vs chain development problem. It's something that needs a blended approach.

I'm for the change if:

1. Accounts must opt-in to the 4 week divestment rather than opt-out of it. The 13 week divestment is a security feature that prevents accounts from being instantly cleared out if compromised.
2. It is treated like an advanced feature and not like a simple click of a button. Frontends should commit ahead of time to provide sufficient information to users who are selecting it.

We have to recognize that while we're aiming to improve our attractiveness to investors we're also reciting "mainstreaming" like a broken record. There's no way to mix advanced and basic. If we try we'll end up with something that doesn't work for anyone.

There are rolling waves of phishing and hacking on Steem. We recently suppressed one such wave. Accounts that are compromised may not know they are compromised as they rely on posting authority through myriad dapps, which does not inform them something is wrong when the hacker changes their keys. It usually takes up to a week for an account to notice they are hacked and their funds are being moved. If they lose a quarter of their powered up STEEM the results to those investors and to the retention of same would be devastating. There's this perception that most phishing victims are new users with no investment. That's false. Most of the victims were active for months if not years and either accumulated or invested their stake. The largest hack (irrecoverable) was about 36k STEEM and the next one down, from an account that then invested and became a whale, was 10k. The opt-in should have a timer of at least 7 days but preferably 30 days, same as other key functions, before the opt-in takes effect. That would add another layer of protection.

Other forms of exploitation that we like to call "abuse" are highly likely to occur but shouldn't preclude implementation. Removal of a capability to halt a potential minor risk isn't the correct response in my opinion. I treat phishing/hacking as a major risk, for the record. Those who haven't been victims yet may disagree but anyone can be next.

At the same time the 4 week schedule holds merit for advanced users who know how to safeguard and monitor their wallets and are active traders. Tying up capital that can be used for trading is pretty stupid. Tying up capital is however necessary to outfit projects and to obviously perform basic functions like curation with any level of enjoyment. Those same advanced users should arguably have the capability to swap their trustee account and recover themselves if compromised.

Whether a divestment schedule change can attract investors is another matter. We're assuming that it will. It's going to take developer hours and a hardfork, both of which are expensive for everyone already invested and involved. Granted it can be bundled with the next planned fork, which would make it more acceptable to the ventures. It's still going to take time from the development team no matter how the code will be approached.

We need to answer the following before we start to the best of our ability:

1. What quantifiable estimate of value is it projected to add?
2. How will this change be communicated to new investors?
3. Will it cause rapid divestment by the current investors?