So what are the tradeoffs, you may ask? Well, you will have some memory overhead loading everything in, and yes, there are some small performance hits in some areas because of all the extra unused capability in the system. Playmaker isn't optimized for any particular type of game, and neither is Unity. But today's hardware is so powerful that unless you are doing something pretty crazy, you probably won't hit the wall any sooner than you would using other approaches.
Another trade-off that I encountered was that due to a couple of levels of abstraction in the game-making process, you can sometimes feel helpless to fix problems. I would find a bug and spend days trying to fix it, and be clueless to the source of the problem. I imagine this is common to some extent in most games, especially where you use someone else's engine/code/API; however, when you are using an engine with a plugin to that engine, things can get tricky. Luckily both Unity and Playmaker have excellent support, and I further mitigated this by working directly with an expert in both Unity and Playmaker whenever I encountered problems I couldn't solve.
Also, while I have yet to encounter this, the more plugins you use with Unity, the higher your chances of conflicts, or of the creator disappearing/no longer providing support. If you are selecting plugin(s) to use with Unity, I suggest choosing ones that have been around for a while, receive frequent updates, and whose creators are active in their own forums. In my case, Playmaker actually supports my chosen interface plugin, which has also been around for some time, which was very handy.
In terms of game design, Unity and Playmaker are great in allowing you to focus almost entirely on building and testing ideas as quickly as possible. I'm personally focused on game design, so this allows me to create ideas and prove/disprove them quickly, getting in as much practice and experience as possible in a short time span. I jumped out of games into a business and back again a few years ago, so I feel like I'm getting to make up some lost ground now!
If you're a game designer at a typical large studio, you might be making "safe sequel number 9999," and while you may have some room to move, you can hardly flex your muscles and push yourself in terms of wildly different or unique designs. If for example you're a designer "stuck" making say, racing games (happily or otherwise) you could practice in other genres with relative ease and low time commitment.
I also believe that the fewer people you have on a project, the more unique and singular the design vision will be, creating more individual games. Using these tools almost puts you into a team that has created a graphics/physics/animation/etc. engine and lets you run wild with whatever design you like, with little in the way of restrictions.
I'm also a big fan of lean startup principles, a concept that Eric Reis is famous for. Lean startup is mostly a business approach where companies attempt to prove product or service ideas prior to launch, then quickly develop a minimum viable product (MVP), iterate on it, and get customer feedback as quickly as possible. This is the opposite to how games are traditionally created, where you define the game first via a design document, make the game, then hope it will sell well.
For lean startup strategy, I think this combination of Unity and Playmaker is certainly something to consider for both large studios wanting to prototype ideas/MVPs quickly, or for solo/small teams, especially if you lack a coder and just want to dive in yourself! Throw in Kickstarter (a crowd funding solution), and you have a very nice lean startup strategy of game development where you can quickly create a prototype, develop a Kickstarter pitch, then prove whether people would pay for your game before you have heavily invested in it.
(If you'd like to know more, you can read Tyler York's Gamasutra article on lean startup for games.)
So how did I follow the lean startup approach, exactly? Well, I did and I didn't. Because this was my first Unity title, and I was going to be learning a lot, I picked and chose various concepts from lean methodology while I decided to play it safe and attempt a fairly proven game concept. I looked at Tiny Wings, Dino Run, Dolphin Olympics, and other games that were similar, and decided that because those games have had some success, that I was already aiming for a concept that would have a good enough chance of success. If you like, you can go the whole hog and try to prove whether your idea would be popular by creating banner adverts or text ads on Google or Facebook, and see what sort of clickthrough rate you receive.
I then chose an art style that I was familiar with -- I have 3D art/texturing as my background, with no animation required (I have no skills there), no AI, and just an extremely simple game mechanic that I could tune based on feel. My minimum viable product was done in days due to Unity's built-in physics; I showed some friends who approved, and I was then on to the finished product.
From my work on Zombie Outbreak Simulator, I was also familiar with freesound.org, where I sourced almost every sound in the game, quickly and free! For music, my friend Rhys Lindsay recorded me an awesome spaced-out track. This left me to concentrate entirely on the learning process and fine-tuning the game.
I would say that I followed lean startup mostly in respect to creating an MVP and final product with the minimum asset requirements, minimum spend, while iterating quickly and often. I honestly was a complete coward in terms of getting early feedback from anyone but friends, as I was genuinely scared that someone would steal my idea while I crept along at a snail's pace learning how to make it. I also just wanted to make something that was uniquely me, with little outside feedback. Funnily enough, towards the end of the project, I found it really helpful and great fun to work with testers and get their feedback. My apologies to them for not being able to add more planets! Perhaps in a future update!