We have a customer who's been long suffering from Microsoft Access troubles. Like many small companies they have a custom-built application written in the Access dialect of Visual Basic, storing the data in an MDB file shared over the network. This sort of architecture is very popular, because it's easy to get an application written quickly, and there is no complex database server configuration to worry about.
This setup always seems to work in testing, but when it goes live and the database starts to get a bit bigger, and more users are hitting it for requests, things start to break. Access seems to have bugs which can corrupt the database when there's a lot of activity in the MDB file.
The end result: having to stop everyone and get them to shut Access down so that the database can be repaired, or even worse having to restore from a backup and redo hours of work from paper records. This just isn't acceptable when solid database servers like PostgreSQL and MySQL are available for free.
I'm sure that there are cases when a quick-and-dirty solution is still the best bet, and you may have inhouse Access skills that make anything else seem unreasonably expensive, but it's important to weigh the risks before diving in. It may be worth scripting some stress-testing queries, and running them from several client machines at once, to evaluate the reliability and performance of Access before betting the business on it.