TL;DR
Regardless of your role, this is a project management site. I will therefore answer from the project management viewpoint, rather than the (perhaps expected) engineering perspective.
Your role as a project manager isn't to justify anything. Your obligation is to raise issues that impact scope, budget, time, or quality in a way that senior management can leverage to make data-driven business decisions.
Use real data relevant to your project to make a business case. Then senior management must live with the results of their business decisions, whether positive or negative.
Establishing a Business Case
The issue is that some of developers are using JetBrains IDEs like PHPStorm and Idea and don't wish to migrate to other tools. Intuitively we understand why those IDEs are better and why using them we will improve our productivity. [emphasis added]
"I don't feel like it" is not a valid business reason for anything. In order to make the case for a budget expenditure, you need to define the need (and the value proposition) in business terms. If you can't do that, then you don't actually need whatever it is.
Whether or not IDEs improve productivity is arguable. As a highly technical executive, I might decide that I'd rather spend my limited project budget on people rather than licenses. I might choose to hire programmers who are comfortable developing on the command line rather than ones who need an IDE to be productive. On the other hand, if I already have a team of developers who are reliant on an IDE to be productive, I might view licensing costs as justified to meet my timelines or quality objectives given the labor force I already have.
In any case, the project team first needs to determine if what they have is a need or a want. Once that's done, any request for a budget appropriation needs to be cast into business terms such as cost/benefit, return on investment (ROI), licensing vs. labor costs, or budget vs. schedule. Metrics and justifications that apply to your project team, rather than to other random people on other projects, will also help.
Establish a Baseline
Since a project must either adjust scope, budget, or schedule, work with the team's current level of productivity (whether you have IDEs or not) to baseline your project. You can't base a project's schedule on people or tools you don't have; you must base it on what resources you can actually apply to the project.
If the team's velocity is insufficient to meet management targets, then you can't simply "beat the staff until morale improves." Management must either hire different people who can work within whatever limitations they set, remove the impediments (e.g. by changing the process, schedule, or toolchain), or accept any demonstrable drag on productivity.
By baselining in this way, you are also providing a starting point to validate (or disprove) any ROI metrics post-facto. Without a measurement of your current levels of productivity, it will be very hard to demonstrate any deltas from a change in process or tooling. It will even be difficult to establish a use case, since without a baseline you can't actually quantify any potential benefit to a project control or resource.
In short, measure what you've got. Then use that to build a quantifiable business case or adjust your project schedule.
