As someone who's worked a bit in theoretical CS, I think this is attributable to theory's different culture. In theory the focus tends to be more on intrinsic qualities of the problem in question -- does there exist a polynomial time solution? a sublinear time solution? how is it like or not like other problems? -- and less on clever engineering ways to optimize the constants in the problem, which is why the implementation (and its attendant constants) often seems like an afterthought.
This is more useful than it sounds, since studying problems themselves can often lead to generalizations ("ah, this is NP-hard") that let you import plug-and-play knowledge ("we shouldn't expect a polynomial time solution").
But yeah when it comes time to implement/simulate, papers that are hand wavey with constants get annoying.
I've seen this happen in papers that "just" presented something as simple as an image thresholding function where the exact code took less than a dozen lines of C once I'd reverse engineered from test data what the constant their method relied on that they'd unhelpfully left out.
The implementation in fact took less space than their plain English description...
For papers that are deeply abstract and focused on solving a problem of the nature you describe, that's to me very different, and clearly there are papers where you won't get around using maths to communicate the problem well. But at least in the fields I've worked in, those kind of papers are rare exceptions.
This is more useful than it sounds, since studying problems themselves can often lead to generalizations ("ah, this is NP-hard") that let you import plug-and-play knowledge ("we shouldn't expect a polynomial time solution").
But yeah when it comes time to implement/simulate, papers that are hand wavey with constants get annoying.