Good question. Today we are incredibly biased into base-2, using it many times where we should be using base-10 instead. So the performance of our current software is not a good example.
But maybe we can get a good example if we just divide our current numbers by instruction types and multiply the FP time by ~100.
I have seen many studies that measure how much time software spends on FP instruction. But unfortunately, we live in a web search dark age, so I don't have references. I remember that FP-heavy code spends 10% to 20% of the time on those, what means that emulation will increase your execution time up to something on the 10x - 20x range. That's perfectly fine for a lot of applications, but does limit several niches.
But as far as I know, the question of how FP-heavy is the FP-heavy software that does daily calculation is unanswered.
What kinds of applications do you have in mind that are (a) CPU bound (or GPU bound), and (b) would benefit from your 'saner' numbers?
Eg graphics in general or video decoding specifically is definitely something that does a lot of processing; but I don't see how it would benefit from eg base-10 numbers?
Spreadsheets might benefit from base-10 numbers by default; but they are not CPU bound at all. Mostly they just sit around and wait for user input.
ERP is all about numbers, and lots of them. While you may rightfully argue that it's a job for SQL servers, the lack of fast base-10-exp numbers in apps creates a very inconvenient and performance-bound gap in development of these systems.
Also, ieee754 floats usually leak into most general purpose scripting languages from the fast-ish category, cause there's no hardware alternative. Two main issues with this are: 1. people who do scripting may be unaware of numeric issues related to base-mismatch, 2. "domestic" calculations and formatting still become cumbersome for those who know. Another issue is that to properly build decimals in (think native + - / * operators), you have to modify the language model around that, and it comes with all sorts of prices.
In short, people want the results to compare correctly to their pocket calculators. "A human number is [+-]<decimals>.<decimals> in a ~20-digit-max window" is an idiom everyone is familiar with and all business requirements assume that by default.
But maybe we can get a good example if we just divide our current numbers by instruction types and multiply the FP time by ~100.
I have seen many studies that measure how much time software spends on FP instruction. But unfortunately, we live in a web search dark age, so I don't have references. I remember that FP-heavy code spends 10% to 20% of the time on those, what means that emulation will increase your execution time up to something on the 10x - 20x range. That's perfectly fine for a lot of applications, but does limit several niches.
But as far as I know, the question of how FP-heavy is the FP-heavy software that does daily calculation is unanswered.