@Cripto It really depends on what is practical for the application's users. A first step is providing transparency and adequate warnings to the sysadmins. For example, a report that lists all of the software components that exist in an application, along with their versions (and custom code changes if any), and a list of publicly disclosed vulnerabilities that affect those versions, and ...
... explanations of the security implications of those vulnerabilities (written in in a way readable by sysadmins), will help sysadmins make an informed choice about what action to take with respect to each EOL component. As you may have guessed, replacing the component may or may not be a practical choice. Thus, mitigations need to be considered. The three guidance you listed can be used as either recommended system configs or mitigations.
SaaS (software as a service) is often touted as a way to "outsource" the EOL problem to someone else.
