I think nuance gets lost in these conversations.

Your distinction between the practical and the theoretical is important. Practicality is important - everything we do is a matter of practicality of means or method, even how we pursue theoretical ends - but two points.

First, there is more to life than the practical. Some truths are known for their own sake, even if they also tell us about still more profound truths (also known for their own sake) or may have incidental practical relevance and consequences in some other context.

Second, while the theoretical terminus is the truth for its own sake, the practical terminus is always something other than itself. Well, what is that "something else"? You can't have an infinite regress of practicality. The meaning of a proximate, practical end is always other than itself. The practical requires an end beyond itself to justify it.

I agree that most people don't seem to inquire much about such ultimate ends. Their thoughts are confined to the proximate. Of course, how have they determined what the proximate should be? Something for people to contemplate.

Where science is concerned, it depends. On the one hand, there are fields that are certainly more theoretically oriented. It's not "the game" that motivates theory - that would make it mere recreation, with the truth taking a backseat - but the truth. (For this reason, I hesitate to call Erdos theoretically motivated. AFAICT, he was motivated by the challenge of problem solving and not the truth, insight, and understanding to be gained which would have been merely incidental and instrumental for him.)

However, I would also say a good chunk of science is motivated by a background motivation of technology production and the mastery of nature. Think Francis Bacon who viewed science as an instrument of power and showed a preference for the "how" over the "what" (τόδε τι) or the "why" (τὸ διότι). This set the tone for a great deal of modern science. A great deal does less explaining and more predictive modeling, because predictive modeling can be sufficient for control. Indeed, a truly theoretical causal account and understanding of a thing's nature can be less useful as a practical instrument than a merely predictive model.

Now, AI is a practical tool. I think they can be enormously useful as research aids, even in theoretical contexts, provided that one

1. understands their nature;

2. understands the purpose of the theoretical activity undertaken.

What is their nature? Well, they're statistical models that can unearth interesting and useful correlations and patterns. But they are not reasoning and knowing things. Their results are generated mechanically and mindlessly. Knowing this means taking their results with a healthy skepticism and a critical eye.

What about the purpose of theory? By analogy, think of a student in school who uses AI to complete all his assignments. Has he satisfied the purpose of those assignments? No, because the purpose of the assignments isn't to produce the effect - the solutions - per se, but to learn something. Theoretical work is like that; it's purpose is to understand and to grasp some truth. An AI can be used to assist this process, just as a calculator or a search engine can, but if you use it in a manner that circumvents that purpose instead of supporting it, then you're not achieve that purpose and wasting your time. What's the point?

I'm not sure why you're being downvoted, but I agree with all of your points. Those aren't things that pretty lend themselves well to mathematical modelling. But... there is a marginal field of math that does apply to this: statistics. The first two cases are somewhat special: - It may be daily obvious that an API is terrible, and that the replacement is not. If API 1 takes 1 sec to call, and API 2 takes 100ms to call, straightforward choice without stats. - provisioning can be dangerous. While not really a stats problem, you do need to have a quite elegant model of what is getting refactored, and how to know when to invalidate those cache entries. For the rest of the examples you provided, you're making changes that may make the problem better, may have no effect, or may make the problem worse. You completely need to use statistics to determine whether or not changes like those are honestly having an effect. Performance analysis is part math and part art, and without the math background, you're likely going to be spinning your wheels a bunch. Beyond stats, fields like queuing theory are going to make a massive breakthrough when you're doing performance breakthrough in distributed systems.