Not really, your understanding seems to be correct. Pretty much every web browser (and most other HTTP clients) will send a user-agent string, so arguably any request that arrives without one is pretty sketchy-looking. On the other hand, it costs basically nothing to send one (for example, with curl, use the -A argument) and is not guaranteed to have anything to do with the truth. Most clients, including browsers, let you spoof the UA string as anything you (the user) want it to be.
Of course, if you tell the server that you're IE 5 running on Windows CE, you might get back some really abysmally shitty HTML/JS - many web servers use UA strings to send different versions of web pages based on the expected capabilities of the browser making the request - but that's your problem, not the server's problem. Same goes for sending no UA string at all.
Security-wise, you could maybe put a speed bump in an attacker's way by blocking requests with no UA, or with an untrusted UA, but all that an attacker has to do is just spoof the UA of, say, the current version of Chrome (which is easy to find and easy to use). It's nothing more than a speed bump. I wouldn't even call it defense-in-depth, since it's so trivial to bypass.
I think your service provider really doesn't grok security, and is falling for what I call the "no legitimate user" fallacy (not to be confused with "no true Scotsman"). It goes like this: "OK, so there's a security threat if the user [does X]? Well, no legitimate user would do that, so we're safe." In this case, [does X] seems to be "spoofs their client's UA string". A lot of people just don't understand that an attacker can, and will, impersonate a legitimate user well enough that you can't reliably tell the difference until you've been exploited.
Well, either that or they just aren't aware that the UA string is nigh-meaningless and trivially editable.
