Implications of leaving admin UI accessible to non-admin users

What would the benefit to an attacker be if they could see client-side code they are not supposed/allowed to use?

It may be easier to exploit vulnerabilities such as CSRF or missing access control if an attacker has access to the client-side code and thus to the requests that may be performed.

It may also be easier to find vulnerabilities such as XSS. Vulnerabilities such as XSS may now also target lower-privileged users as well as higher-privileged users, as both have access to the UI.

Is having such functionality exposed a really bad practice I should immediately address?

Not really. If it's not needed, I wouldn't expose it though, because of the reasons outlined above.

If we assume this is open software (and it is, currently, from the employees' standpoint), would hiding privileged users' tools be just some sort of security by obscurity, since an attacker could check the source code anyway?

If it's open source, it's not even security by obscurity, and hiding it isn't strictly necessary (although still not a bad idea, especially because of the possibility to exploit XSS vulnerabilities).

Must say a self explanatory question written by a man who knows exactly what he wants. You've got some fine responses already, contributing my penny as below.

1. It is extremely common to have code base accessible to developers/testers(employees) however there should be precautions to be taken like if any encryption keys are present they'd not be part of normal code, no plain text passwords in code etc.
2. It is best practice to let people have access to only that information which they need for performing duties nothing less nothing more else it may cause data leakage/breach of confidentiality/breach in the principle of least privileges etc.
3. If an attacker could see client-side code they are not supposed/allowed to use, they will be able to create an attack plan based on the data available (ex form name, name and datatypes of fields, sequence in which they are queried, any default values, development comments etc. Trust me if I had all these details nothing can stop me from taking the site down with dedicated efforts)
4. Yes if this is the case presently then it should be addressed immediately.
5. If this is an open software then also there are scenarios to be considered like Is sensitive data present in code (username-passwords, encryption keys, external communication details, etc)? If yes then this must be handled in a repository which is not accessible to everyone. If you are giving a development environment to employees then make dummy values of these(data scrubbing) and then push it for people.
6. This was all about code repository, come data/application and there will roles, groups and permissions for segregation of access that is mandatory both from DB and code perspective,failure to do so will lead to missing function level access control(you don't want to have that).

Ok I have written too much, to summarize if you keep the application the way it is you are keeping attackers (insider/outsider) optimistic for application being vulnerable to all of OWASP top 10 Risks.

Solutions (you never asked them but I don't want to keep the loop open)

1. Seperate code repository for configurations, use dummy configs in development environment.
2. Never keep anything open/readable in production environment for people who should not see it.
3. Even if it seems open now once it's gonna be open for externals you'll need permissions and access control measures, implement them now and you'd not have to worry about modifying the architecture after a year or two when the code would have grown.
4. Don't give leads/comments/code on production pages that's goldmine for attackers.
   5. Follow OWASP top 10 risk handling guidelines.

I can add more but I feel these would suffice the need for now.