As a software engineer and developer, this is a question I've seen throughout my career, both in terms of front and back end development. Supporting older versions of languages, browsers, operating systems can get complicated and expensive. When publishing packages on github, I debate whether to make packages backwards compatible. Sometimes, you just have to be ruthless and stop supporting older versions. Projects should be designed with a lifecycle in mind, with an idea of how to support the project after it's lifecycle end.
There is no correct answer to what you need to support; however, let's take a look at some points to consider;
If my site doesn't support X, my customer base won't be able to buy products
This is a legitimate concern, companies are often worried that they'll lose sales if you want them to upgrade to a modern browser. Sometimes, organisations will restrict their users to using a certain browser version because they have intranet sites which have not been upgraded. Research generally suggests that with automatic browser updates, we don't have to worry as much about supporting older browsers because generally less people are using them. It is often good to carry out research looking at trends and seeing is supporting certain browsers is necessary.
Security Updates
Whether it be a language, browser or operating system, all versions have a shelf life. When they come to their end of life, they don't carry any security updates which leaves your application vulnerable to attacks. This is obviously not good. It should be a part of any development plan to upgrade the code base from time to time. Languages tend to have a lifecycle and it's important to know what the lifecycle is for the language(s) you're using and chose appropriately whether you're going to use a normal release which generally has a shorter lifecycle, or an LTS (long term support) release which lasts for longer and is supported with security updates, but may not have all the latest features.
Development Time
Supporting older versions can substantially increase development time (and can sometimes drive your developers nuts!) and might not actually add any worth. With each new version whether it be a language or browser etc, features are added providing new functionality while other more outdated methods are deprecated and removed. To make use of the new features the code base needs to be up to date. Workarounds to emulate new features often take a while to do and never work quite as well as the native solution.
Complex code base
Overtime, trying to support and maintain older code within a newer codebase becomes arduous and complicated. Code can become fragmented trying to implement features which wouldn't otherwise exist in the current code base.
Testing and QA time
The more systems or versions you support, will increase the testing and QA time. By supporting older browsers, you could end up having to load up virtual environments to test and quality assure development which in itself will take time. This can equate in a lot more cost because you'll be paying for quality assurance which will take longer just because of the very nature you're supporting more browsers.
Conclusion
At the end of the day you have to consider what is best for your needs and budget. If there is a genuine requirement to support older browsers or languages then you should proceed, but it is prudent to know that older codebases and browsers are more at risk of security attacks.
In an ideal world, all users would use the latest devices and browsers and all codebases would be using the latest languages and framework, but obviously that's not going to happen! Just take a common sense approach and see what works best for your project.