question

To give a little more detailed answer to this question:

No, going to Enterprise is not going to help poorly written code. And I've been in this game long enough to know that this is a case of poorly written code and/or bad indexing.

But beside queries that needs tuning or better indexing, there is another way code can be poor. Some developers inline all parameters, so rather than sending:

INSERT tbl(col1, col2, col3, ...)
   VALUES(@par1, @par2, @par3, ...)

They send something like

INSERT tbl(col1, col2, col3, ...)
   VALUES(14, 'Peter', 'Smith', ...)

That is all parameters are inlined to the query. This means that every query needs to be compiled. Well, almost, very simple queries will be auto-parameterised.

The correct fix in this case is to have the developers to clean up their act, which may take some time. But SQL Server provides a band-aid in this case.

When it comes to upgrade, I think a better path is to go SQL 2016 or later. This is because with SQL 2016 you get Query Store, which makes it a lot easier to find slow-running queries. On SQL 2014, you need to runs traces or X-Event sessions to identify them, and these tools do add overhead themselves.

Yes, there is a license cost for an upgrade. But I guess it's cheaper to go to SQL 2019 Standard than to SQL 2014 Enterprise. (And with SQL 2016+, you can replace mirroring with a Basic Availability Group.)