I think we can test this retroactively. sed has been around a long time. So we can go grab a copy from, say, Version 7 Unix and try to build it on a modern system. I grabbed v7.tar.gz from
https://github.com/v7unix/v7unix, extracted it, and tried to build:
$ make
cc -n -O -c -o sed0.o sed0.c
In file included from sed0.c:2:
sed.h:116: warning: declaration does not declare anything
sed.h:128: warning: declaration does not declare anything
sed0.c: In function ‘main’:
sed0.c:32: error: ‘union reptr’ has no member named ‘ad1’
sed0.c:48: warning: incompatible implicit declaration of built-in function ‘exit’
<snip many more lines>
The problem here is that although sed was written in "C" and we have a "C compiler" on our system, the definition of what exactly constitutes "C" has changed. The modern compiler no longer accepts the same language as the V7 compiler.
We can fix the source to deal with this and produce a working binary. But then, what would we do with it? We can't really install it as /bin/sed. The world now expects /bin/sed to support switches and syntax that this sed does not. Trying to use this as /bin/sed would cause lots of programs to fail. The definition of what exactly constitutes a working "sed" program has also changed.
So it seems to me like sed already has rotted in some sense. Looking forward, the sed from a current system is likely to be similarly rotted when you try to use it on a machine 40 years from now.