I think you're actually asking two questions, which I'll try to split out.
I reckon an advantage would be that they seem to force developers to
modularise their programs using good-practice design patterns. This
seems great for someone in my position. The extra functions they
provide, for example: interfacing with databases in such a way as to
make SQL injection impossible, would be very useful too.
The question is about frameworks conceptually. What you have said is absolutely true. Some frameworks encourage the use of MVC which, in my opinion, is a great way to separate the logic of your code and make it maintainable (abstract is better). There's no net worth to coupling your code to a particular database engine when you can write code once, which will work against any of the popular ones.
The downside I can see is that there will be a lot of overhead for me
in terms of the time taken to learn the framework itself (while still
getting to grips with PHP itself). I'm also worried that it will be
overkill for the scale of the apps we develop.
This part is about frameworks for your project specifically. This is more difficult for me to answer, but I certainly think you should have a good strong look. Even if you only have a 1 model (one table with your data in), 5 controllers (one for each page of data that you want to manipulate) and 1 view (which just takes the data and spits it out as XML), I still think it'll be worth it. Why? Because it's a common and scalable structure. If you find that, in a few years, you end up with 50 XML pages, 50 JSON pages and 50 text pages - you'll really wish you weren't hacking away at the XML code to get it to
json_encode, or toying with
strip_tags because your business logic is tightly coupled with the view.
Also, once you use some of the automagic features if your framework like forms, authentication, ACL and the like, you'll never want to bore yourself by writing this yourself again. It will just take usage of one of these for you to realise that the time you spend reading the documentation is severely outweighed by the fact you barely need to test the end result compared to if you had written the feature ground-up.
The time it takes just to configure the frameworks may not be worth it.
Then pick a lightweight and almost-zero configuration framework. I've used CakePHP quite a lot, but I've heard good things about CodeIgniter too. Cake, for example, has one real file that you need to edit:
database.php. Everything else is optional, and comes in a debugging mode which you can turn off later once you want to deploy your application.
The final problem I can see is that developers in the company – who
have to go over my code, and who do not know the PHP framework I may
use – will have a much harder time understanding it.
I wouldn't even consider this as a hurdle (that said, if you have management policies about these things then you should - I am assuming you have been given a new project with the freedom of how you want to approach it). If the developers assigned to review your code cannot get their head around a simple MVC structure, they are in no position to review code. Frameworks are very well divided: the code your write and the code they give you are in completely opposite locations (essentially). All they are really looking at for you is 3 folders:
views where they should be able to look at each file and see if the logic is what they'd expect.
In the long run, frameworks are the way to go. If you only want to write a script quickly that you'll only be using for a few days, then don't bother.