What are the disadvantages of using the InChI format?
You have to evaluate shortcomings as compared to something. You can make a list and say "but InChI doesn't represent X" where X is ranging around 


mixtures
Markush groups
polymers from repeat units
reactions
toasters


The point is: so what? All representations have some limitations. But limitations aren't shortcomings unless you have a different representation that doesn't have those limitations and that is not traded off by other limitations or bloat or other disadvantages.

What do you have to compare InChI with? In my world: SMILES and with MOLFILEs. InChI is most closely related to SMILEs. SMILES is easier to just type, but it isn't canonicalized and it doesn't have the layers of specificity that allow you to find approximate equivalences so easily as with InChI. InChI connection layer is very similar to SMILEs in principle, but it is a lot harder to read because you need to replace the numbers with the atoms from the preceding formula layer. But it is easy to convert InChI to SMILES, except where InChI is better. For example, parenthesized groups, so you represent the carboxyl group -C(=O)OH as -C(O,O)H, which isn't a thing in SMILES. 

Where InChI shines is that many isomerisms are abstracted or pushed into more detailed layers. There is no other format that does this as well or at all as InChI, which is why it is good. But InChI is conceived as an "identifier" and some of the details are not at all represented, most specifically the atom positions. That's where MOLFILEs are so easy to work with, if you want to just display the molecule. But in that regard, InChI is no worse than SMILES.

So, you should be more specific in terms of what your goals are that you are asking for "disadvantages" and you need to stay very critical of text that berates InChI or any other standard with a bunch of rationalizations for why not to choose standard A (because the author is committed to standard B). I know this sort of superficial argument is being made a lot in any informatics sector, people like their baby and berate the other's baby. Especially be weary of those who say "don't use InChI, InChI is bad" and then "you really should follow the work on XYZ, because XYZ will be able to represent everything including the toaster."

InChI has it's firm place when the purpose is to represent, refer to, identify basic molecular structures. That's it. If you want mixtures, reactions, polymer repeat units, consider using InChI as the core building block and then build higher order structures around it. For example, obviously there is no reason to push reactions into the InChI representation, just make a simple structure that lists the reaction participants on both sides, their stoichiometry and the enthalpy, activation energies, etc. etc., these can be done in higher order data structures much better than shoving that information into a single InChI++ string. Likewise for polymers, represent each repeat unit as an InChI and then combine them. If your goal is such higher order molecules, you would profitably use InChI as the representation of those core building blocks.

Now that said, I give you my personal pet peeve about InChI, i.e., that is in scope of current InChI where I think it has, let's say, pitfalls, not necessarily that it made the wrong choice. And that is, ionic bonds and coordination bonds. Especially ionic bonds are represented as two separate structures, recognizable with the period . in the formula separating the multiple structures. This is actually a rudimentary representation of mixtures. So in my view, it should not even have introduced this dot notation but simply forced people to represent the parts of these ionic mixes as separate InChIs. I come from the biochemical / physiology / pharmaceutical / medical world where such ionic bonds usually do not even really exist in nature, as the ions are all dissociated in solution. But all that can be disputed. Same for metal coordination or chelate bonds, you want to say where the metal ion associates with, and I think that's not in InChI. So in my world it would be better not to have any of this mixing and coordination inside InChI and we would use higher order structures for it instead, but always use InChI as the basic building blocks.