It's a typical scenario with .NET MVC - search-engine friendly URLs are a direct result of proper implementation. But let's have something clear - these are not web directories, but MVC routes, right?
Paranoid pen-testers are often uncomfortable when the admin interface is somehow exposed in the URL, since it can attract unwanted attention, or be harvested and used for fuzzing.
If you want to improve on this, you may need to abuse the ASP.NET routing engine to obfuscate the path, if their concern is that the admin interface is "exposed" - that would be a quick fix, but obfuscation is never the correct way of fixing things.
An alternative is to use a resource manager and routing is based on resource tokens, but that would involve heavy modifications to the application. Each resource has its own resource token ID, and can be dynamically generated when a user logs in. Then every resource (page, style, image) is a link to the resource manager. Then getting a stylesheet will look like:
<link rel="stylesheet" type="text/css" href="/Resource/80af9420ab0401-00291844a/91009abff01">
The same applies to the URLs. This may result in a lot of overhead and poor performance, poor scalability, etc. I do not recommend it, but these days management just listens to whatever external "consultants" they're paying to, and refuses to acknowledge internal talent.
Unfortunately, sometimes it's a question of compromise - security should not be a result of poor scalability or performance...