by Aidan Harding 
I’ve always been wary of Process Builder. My objection is that Process Builder’s main advantage is also its greatest weakness: It offers the power of writing code, without writing code.
While it lets you get more things done without having to get one of those weirdo developers involved, it requires you to adopt a developer’s mindset if you are going to avoid tieing yourself in knots. You have to be able to understand flow control and the system-wide consequences of what you’re doing.
Process Builder has no facility to write tests – and tests are the backbone of any development oriented task. If you tell me you’ve written a function to do something, I don’t believe you until you show me a test which proves it. The tests also protect you against future system changes which break your new features. Without tests, Process Builder is a lot of power with no safety net.
The ins and outs of restrictions and bugs in Process Builder are likely to change over time. Today, there are lots of things it doesn’t do well (particularly around bulk updates), but we can assume that Salesforce will fix these one day. The linked article lists many of those restrictions.
Philosophically, though, I think Process Builder should be thought of as a prototyping tool or something to be used for very simple jobs. It offers power without safety, and makes it far too easy to cause system errors.
Because of all of this it is my opinion that Process Builder should simply never be used at all.