It's not so much that the software does serve as a long term asset, it's that it isn't a static long term asset - it only maintains its value by being maintained, updated, extended. The work that was done on it 5 years ago, or 10 years ago, laid the groundwork for the value it has today, but that value would be zero or close to it without continued work.
That happens for a variety of reasons, including but not limited to: changing platform requirements, deeper understanding of user requirements, changes in user requirements, new external interaction possibilities.
As a small example from my own little world of digital audio workstations: ardour version 2 (from around 2002) was pretty good at doing all the things it did back then. But in 2023, that list of features in a DAW barely gets in the door for consideration as a tool for most potential or actual DAW users. That codebase (the v2.0 one) in and of itself is of close to zero value at this point [0], the only reason the project as a whole continues to have value is that it gets updated and extended to meet the expectations (to whatever extent it can) of users in 2023.
So, is the work I and others did in 2001 (pre v2.0) sensibly treated as a capital expenditure, or was it just "work" ? Further, when an architect designs one house for a client, then another for another client, then another for another client, why is that not treated in the same way? Each house is essentially and R&D project from which the architect carries forward a bunch of acquired knowledge and skills. I think the answer is reasonably obvious: we regard the project as each individual house, not the capabilities of the architect (which hopefully grow over time). With software, it's not clear quite why v2.0 and v3.0 and v4.0 etc. are considered to be "merely" updates rather than distinct projects similar to an architectural project.
Another point I would make about R&D: one of the justifications (I suspect) for having a deducation for such expenditure is that you don't really know if it is going to work out in terms of resulting in a new, or improved, item or service; because we officially want to encourage "innovation" we want to provide a bit of incentive to do the spend anyway ("you can claim it as a deduction").
I just don't see this as true with software work, particularly not software work on existing projects. Uncertainty levels are low - the chances are overwhelming that an attempt to add feature X to an existing project will be successful. And there are, as I described above, more than adequate motivations to do the work - no tax deduction is going to drive adding new features to an existing project in any sane world.
Again, I do acknowledge that there are software development and distribution models that are closer "work, work, work, work for N years, sit back and sell the result for M years, with a bit of maintenance work on the side". It seems much more appropriate to treat that as capitalization. The IRS allows people/companies to make a choice between cash-based expensing and amortized expensing of many costs - I'd prefer it if they acknowledged the difference for this purpose too, and allowed software development to be "cash basis" or "capital". Obviously, a set of returns that shows years of revenue with very little expense and that claimed "cash basis" would be seen as fraudulent.
I'd also note that the lawyer who posted a link to his Bloomberg article on this matter did not concur that the IRS has "quite clearly" defined maintenance vs. upgrades.
[0] and of course, as pointed out by a sibling comment, not very much remains of that codebase either, further underscoring the non-capital-like nature of software, at least over much shorter time frames than, say, a building or a piece of manufacturing equipment.