In addition to what pm90 already said, if you can't quantify the value to the business on some level, then why are you doing the work?
My comment also said to back up the numbers. If I said I wrote a little utility and it saved the company 8B/year I better be able to explain how.
Also, the numbers do not have to necessarily go directly to revenue. Less bugs, faster feature development, less server resources, lower costs, better estimates, etc... are all quantifiable on some level. Is this an exact science? No, but this is what any engineer above junior (even they should be asking why are they doing something), should be asking themselves about every single engineering task. Because something is new and shiny is generally not a good answer, yet these types of migrations still happen in companies and waste large amounts of money.
e.g. it could simply be how much client data is processed by your system everyday, how many clients use it, what is the ultimate value the pipeline generates (even if that may be the cumulative value generated by the entire software pipeline)
This is important for any level job. Java to Go by itself is really only interesting for a low level position. 8MM revenue growth is a person that will almost always get another look. In general, using exact numbers that can be backed up is better because they tell the why.
Using the Java to Go example. Sure, the work was done but why was it a good idea? What did the company receive out of the change? How did the interviewee think about and mitigate the risks?