Can you use a MySQL database as a shared source of user accounts? Yes, definitely. I have mounted such system and it works quite well with multiple applications.
So, which are the drawbacks of using a MySQL database instead of LDAP?
a) You need to adapt all the applications to use your database.
It's usually not a lot of work to adapt an application. Often, you can just solve it by making a view that adapts the column names. Sometimes, you may need to add a bit of code to cater for a different password hashing format, or to create an authentication plugin.
However, you will need to do that for each and every application. And when you are asked tomorrow to install a new web-application (e.g. someone decides to add a Wordpress blog), you will need to do again study the application and see how to adapt it.
'Everyone' supports authenticating against LDAP. It is the de facto standard, and you will find plugins for doing LDAP authentication on any application with a decent size (and for those that don't, there's a clear case for implementing that). There are a few (very few) alternatives, and they have little support for being used for authentication.
Also note, if an application happens to use a different database engine (suppose there is a new development that requires using PostgreSQL), it may be harder to additionally make it support a user table from a different engine (mysql).
Of course, the adaptation itself, you can only do that if it's your own development or open source. Forget about getting Microsoft Windows to support such custom scheme!
b) Security centralization
Using a central authentication server has multiple benefits:
For one, if you have a central server, and someone tries to bruteforce the password for user
john, a common setup is to have it block the user for some time (or until manually unblocked). If you have a dozen of services, even if all of them had some throttling measures (hint: they probably don't), each of them would be separated, and by attacking multiple services an attacker would actually have N tries times number of services. You would need to coordinate that metadata into the shared database, and all the services to check them and implement in the same way (more code to add to the applications, mail and ftp servers...).
Second, central logging. Performing authentication on a single service allows you to have a single authentication log, rather than having it split over multiple places.
Third, it is a single point for updates. You want to move away from MD5 hashes to use pdkdf2 or Argon2? You only need to update the authentication server to support it. Else you would need to get each and every service to support that new format.
Fourth, greater isolation. If all authentication goes through the central server, it should be configured so that he is the only one able to read the sensitive data, and you can concentrate your efforts to make sure it is secure. However, if every service needs to verify the user passwords, you have a much greater surface: a SQL injection vulnerability on any of them would allow dumping the list of users and hashes (and I am already assuming that it was made read-only, otherwise they may even be able to modify them, or insert fake users).
Please note that you could solve (b) by having a central server that didn't use LDAP at all. But given (a) it makes sense to keep using LDAP protocol for authentication.
There's no reason a LDAP server mainly used for authentication couldn't use a MySQL database for storage. In fact, LDAP is much more potent than the typical use it gets (which is why it looks so daunting). However, I am not aware of any implementation doing that.
My recommendation is to keep your current LDAP server and create if needed an interface for performing the most common actions on it (there are multiple LDAP frontends, maybe one of them would cover your IT group needs?).
If you wanted to change your custom web applications login process, I would make them to support a Single Sign-On solution such as SAML, but I would nonetheless still have it use that LDAP backend, which would be shared with your FTP, mail and other services.