When a user interface is in, say, HTML5/DOM, one needs to know a lot about controlling how often the browser reloads the page or a portion of it, how much CSS is "too much" before the page rendering is slower than tolerable, how to control a loop to minimize server calls and DOM redraws, and much more. Similarly, a lot of UI is search optimization, deciding how much power of the search goes into the server/db and how much in the UI, then how to find and highlight the search results - all of these are complex processes that can be painfully slow or dramatically fast, but only if you know what bottlenecks to expect.
Anybody can draw a UI on a piece of paper and bullcrap the thing up in jquery-ui or xcode. Making a UI that is functional amidst constantly changing requirements involving ever increasing quantities of data is much harder. Writing components or maintaining frameworks and understanding the decisions the framework designers made (so that you don't violate them, often with painful results in stability or performance, when using them or adding to them) is a huge part of REAL UI work. I have yet to meet a toolkit I didn't need to fix or amend to, in 20 years of UI work. I have yet, in any of those libraries/frameworks, to NOT have Big-O decisions to make when doing so in pieces involving components meant to handle large amounts of data like grids and graphs.
No, it doesn't happen every day. But it happens at least every project.
If you don't speak basic optimization rules/practices like O(N) vs O(log(N)) (and yes, that HAS come up more than once in my work in the last 5 years, nevermind the last 20 when I was doing more J2EE or MoM/Agents work), then I can't trust that you have any discipline to anything else. There's no point in even talking anymore if you can't speak what I consider to be a basic common CS vocabulary.
Yes, much of this is trust: the piece of paper that is a degree is something of a document of trust that you have had certain disciplines and experiences, things that I can't actually get directly from your work prior since I'm not actually allowed to ask to see your code in an interview or before-hand - that usually belongs to your former company.
We don't ask for higher maths because we expect you to use them; your 'experience' during your degree work is almost meaningless in-and-of itself. We ask for higher maths, and for the other aspects of a degree, because the degree is evidence of experience, motivation, and most importantly discipline.
And for many of the "I don't need maths blah blah blah a trade school is fine blah blah blah" posts on this thread (and this same thread every time this topic comes up, which is probably twice a year for the last 18 years I've been on