It is a practice. WPA2 uses this sort of approach, for example. Whether it increase security or not in your particular example is a more nuanced question.
Let's start with AES-128 and a 128 bit key as a baseline. This would be the obvious solution. At the moment, AES-128 is very hard to break. But perhaps one is worried this might not be true in the future. AES-256 offers some future proofing (or at least it appears to offer some future proofing... devil is in the details).
So we can upgrade to AES-256 and use a 256 bit key. This would also be an obvious solution. It would give you all of the perks others have mentioned in other answers. But what if there was a reason they couldn't use a 256 bit key? I cannot speculate why one would be unable to use a 256 bit key. But let us, for sake of argument, assume that there is indeed a reason they can't use a 256 bit master key. They have to use a 128 bit master key. Maybe there's some backwards compatibility issue, or maybe the CEO was born on December 8th. For whatever reason, we find ourselves limited in this way.
We could just concatenate the 128 bit key with a bunch of zeros (or any other known value) to get a 256 bit key. That would get us many of the advantages of AES-256 (such as the extra rounds), but we would still have only 128 bits of entropy to brute force. That's currently "enough entropy" for most uses, but it's not 256.
Now AES is designed to be fast. Very fast. And energy efficient too. These are all great things for a crypto algorithm, but they're also great things for an attacker. If the attacker knew the key expansion was just concatenating zeros, they much be able to attack that directly, and they can attack an algorithm that was designed to be fast.
Enter PBKDF2. This is an algorithm that is designed from the start to run slow. How slow? Tunably slow. You pick how slow you want it by changing the number of iterations of an inner algorithm. WPA2, for example, chooses to iterate it 4096 times.
If you use PBKDF2 to expand your key from 128 to 256 bits, then use AES-256, your situation is better than if you just concatenated zeros. You still only have 128 bits of entropy -- that never changed. But now if they want to crack the problem where its only a 128 bit problem, you have to go through PBKDF2, which is much slower than AES. You don't know what iteration count they chose, so we can't calculate how much slower, but in theory they chose a count with the intent of making it very slow.
Meanwhile, the data is encoded with a 256 bit AES-256 key. This 256bit key does not have 256 bits of entropy. It only has 128. You can only get what you put in. But it is a 256 bit key. And, importantly, its hard to determine which 2128 keys are possible outputs from PBKDF2 (with known parameters, including the salt). So in theory, if you want to attack the fast-to-attack AES encryption, you have to do it on a 256 bit key space. If you want to attack the smaller 128 bit key space, you have to do it through the slower PBKDF2.
So in theory, you are safer using this approach than just using AES-128 or using AES-256 with a simple key expansion algorithm. However, the devil is in the details. When you start layering algorithms like this, you don't get to mentally add the security they provide. You actually double your attack surface. If there's an issue with AES or if there's an issue with PBKDF2, it might break your system. However, against brute force attacks, this will be very strong.
The closing caveat is a reminder of the odd choices this company made. Why not have a 256 bit master key? If you did, all of this gets very simple. It only got complicated because there was a desire to have a 128 bit master key. In some cases this pattern makes sense. In the case of WPA2, using PBKDF2 to feed AES like this makes sense because the key is generated by an average user, who knows little of security, and would have difficulty generating a password with 256 bits of entropy. It is unclear, with the details not provided, why a 256 bit password could not be generated in your case instead. But perhaps, with more details, one could come up with an argument for why their pattern makes sense. We do have evidence that it made sense in at least one domain, WiFi.