More accurately, I personally don't have the skill to alter Box2D to meet my requirements. For example, it naturally isn't built to allow jumps through platforms. You have to kind of hack it in what is, to me, a convoluted way. When I first tried to implement Box2D, the character stuck to the sides of walls while you held the left/right arrow keys against them, which shouldn't happen, so you had to work around that. To me it's just much cleaner to do it from scratch and plan directly for what you need the code to do and you're not fighting an existing library/engine. Again, I have no problem if someone can do miracles and make it act like Guacamelee but to me (and apparently many successful studios) it doesn't make sense.
Rendering Engine =/= Physics Engine.
Disclaimer: when I talk of physics engines, I also include the collision detection, because those are usually quite tightly linked in many engines.
It makes sense to replace the physics engine with your custom physics if the standart physics behaviour gives you headaches. Altough you probably can hack the physics engine to do your bidding (like switching off collision for platforms above the player characters position just for the player characters collider), and this might be a faster way to achieve your goal than having to write code to calculate the trajectory of your jumps, with every new hack needed because the physics just don't behave the way you want it to that balance shifts in favour of rolling your own custom physics (which most probably are very simplified anyway for a guacameele style game).
Just because you roll your own custom physics doesn't mean you have to write a renderer from scratch though. All the off the shelf engines I have seen so far allow you to use the engine internal physics. Or just ignore it and write your own physics scripts.
It's not the most performant way to do things certainly, but then off the shelf engines themselves are usually less efficient than writing your own code from scratch... its a trade off for getting a pretty good base to start from for games that are not extremly simple thus need quite a lot of the engine components you would have to write yourself else.
And then there is the fact that guacameele is hardly making even a low spec PC sweat. This game probably would run fine on a mobile phone. So I don't think you need to squeeze the last bit of performance out of your game to get it to run on PC.
I don't know Box2D, but I guess you could also just replace the physics with your own in there (or hack the physics the way Drinkbox has done)... certainly you will pay less to have a programmer fix you physics issues in Box2D than write a renderer, a physics framework, a level editor and whatnot else for you (or integrate existing products into a complete framework).
physics engines hardly ever work for a real game out of the box, and I speak from my expierience here as well as what I heard from quite big AAA devs that tried to integrate physics into their games. Physics engines try to simulate reality... something few games can really use.
Most games that need physics and use an off the shelf physics engine for that have to hack it to do their bidding, because you want a realistic jump trajectory for example, but snappy controls on the ground.
