It's not that it's super hard, believe it or not. It's that it creates a blockchain bloat problem and there are many non-consensus solutions to that problem the most obvious one being reposting.

The most important point I want to make here is that the decisions that are made with respect to Steem are always based on scalability and utility for developers. Developers need to be able to do what they need to do and they need to have confidence that the platform is going to scale with their needs. Not every thing needs to be fixed on the blockchain level. In fact, very few things need to be fixed on the blockchain level and the more things that are fixed on a blockchain level, the less scalable the platform becomes because blockchains by their very nature are difficult to update. Therefore, if the blockchain can be used as the backend, while a user interface can be used to solve a problem on the front end, then the front end solution should always be favored. Any project that violates this rule will not be scalable, regardless of grandiose (and baseless) claims.

So how can the problem of rewarding evergreen content be solved using Steem? Quite easily. On steemit.com we want to encourage new content. A platform that wants to focus on "evergreen" content can automatically repost content every 7 days on the backend without showing any change in the interface. If the content truly has evergreen value, no one will object. Another solution would be a dapp that only reposted a piece of content after it receives an upvote. E.g. A post is a year old. It has not been reposted. A user upvotes the post through a user interface. On the backend the post is reposted to Steem and given an upvote by that account. From the user's perspective the content creator's post was rewarded. From the content creator's perspective they were rewarded for their evergreen content. Nothing was changed about Steem. Steem remained scalable. Blockchain dev time was spent on something more important than solving a problem that was easily solvable on the front end.

Now I've heard the response to this: it's too complicated. Actually, it's quite simple for developers and if a developer can't code this, they're not really a developer. The reason we have a 7 day limit is because most content receives most of its votes in the first week and infinite payouts leads to infinite blockchain transactions, which is unscalable. The fact that most content receives the majority of its rewards early on means that infinite payouts are an edge case, i.e. not mission-critical like hivemind, SMTs, sign up, etc. The fact that infinite payouts is not scalable, means that you would be destroying the blockchain for a non-critical edge case. Why are infinite payouts not scalable? Because if a potentially infinite number of posts can receive votes for a potentially infinite amount of time, then the number of transactions will trend toward infinity. It's also important to remember that most upvotes have very little value, so it's creating an infinite number of txs so that mostly low-value upvotes can be made to the blockchain (as opposed to UI-only upvotes). For this reason, post rewards need to be bounded somehow. The 7 day limitation is how the Steem community has chosen to bound the potentially damaging outcomes. Of course, this is an open source project, so if someone solves the problem in a scalable manner, submits a github PR, and there is consensus among the community that it should be adopted, it will be adopted by the witnesses and the blockchain will be updated. Anything other than a PR is just "tawk." Anything for which there is not significant consensus, is also, just "tawk."

All of that being said, I will reiterate that infinite payouts are already easy to code on Steem. We simply choose not to implement them because we do not believe they are right for this product. What the 7 day limit means is that developers have to consciously choose to increase the load on the blockchain and deal with the consequences if their app is interpreted is adding spam to the blockchain.