Alright, finally had some time to sit down and detail this out. I'll first respond to Mike's response as he hits some good points and some points I'll counter.

Mike's Use Pods If:

(a) Agree

(b) Agree

(c) Agree

(d) Agree -- Pods is very PHP experience heavy in it's current version - though you don't have to know PHP because you can copy / paste simple stuff, but someone with a lot of PHP / OOP experience can do wonders.

(e) Agree and Disagree -- Disagreeing because in some cases, it makes sense to duplicate functionality on a project when it simply can't be hooked into in WP Core (though you wish it could be otherwise).

Mike's Don't Use Pods If: (lots of counters here)

(a) Disagree -- This is more of a clarification as you CAN create Themes / Plugins around the Pods CMS Framework, just distributing the plugins and themes as Pods-based just raises the bar as the user will need to install the Pods plugin itself on their site. Good theme and plugin developers will add functionality in their theme / plugin so that it won't break a user's site upon installation in which Pods does not exist, it will simple give an error on activation or in a theme's case - not run the Pods-related functionality. If you're developing multiple plugins that need to talk to each other, making them Pods-based actually decreases the need for additional code to be distributed w/ each plugin meaning they can share resources via Pods (both code and ease of implementation like w/ PodUI in 2.0).

(b) See my (e) above in the 'Mike's Use Pods If' section for my counter on this.

(c) Disagree -- As with just about any 'Con' of using Pods, Pods 2.0 is a game changer as it allows for more direct integration of Pods in core WP theming and implementation. Also, as with any custom plugin - there will always be some worry of the work you do working in the future. When using Pods and Pods UI, you can implement a lot of things with very little custom code. By doing this, the user / future devs can upgrade Pods and WP to gain additional new features and fixes as they are made - while your hugely custom plugin, if it's not intended to be supported, would need attention on each upgrade to ensure compatibility. Either use Core WP functionality if it fits your needs exactly, or if you want additional features, use something like Pods to limit the conflicts that your plugin could have in future versions of WP.

(d) [or (e) as Mike accidentally listed it as] Disagree -- Only in the case of Pods 2.0 as Pods now is still quite PHP heavy and the UI is confusing, in 2.0 this will be cleaned up significantly enough for a beginner to come into using Pods and integrate with core WP theming which requires little to know Pods-specific knowledge.

My own thoughts

Pods itself, is simply a plugin that uses WP core functionality and extends it. You could build anything (like Mike said) with WP Core, but does it make sense to do all that extra work for something that won't be maintained and supported like a plugin like Pods? It's like trying to decide if you're going to use a HTML-based site or if you'll install WP and get all the benefits. WP, after all, is only a dynamic site that outputs HTML. Sure you could build a whole site hard coded, with limited dynamic functionality (or code your own via PHP or whatever), but then you're talking about long term maintenance of a mess that's straight out of a toddler's toy chest.

There's been a lot of talk that you should code your Custom Post Type stuff yourself as opposed to using a plugin. Well, let me just say that in certain very very very simple and extremely performance oriented situations - that does make sense. But when you need a ton of extra functionality, you'd be making negating that argument. Pods is a framework that lets you do a WHOLE LOT with very little code and maintenance on your side - which is exactly what WP itself aims to do by lowering the bar to building out a site.

Hey Tom, thanks for posting this. Lately my decision criteria has been the following.

Use Pods If:

(a) Performance is a concern, or (b) If you expect to frequently need complex searching and filtering functions, or (c) You need a wide variety of very unique content types (i.e. think about education environments as a good example), and (d) You are comfortable with PHP, and (e) Do not need or expect to duplicate or reproduce much of the functionality.

(I know item 'e' is one Pods developers would dispute).

Don't Use Pods If:

(a) To create plugins or premium themes, or (b) Reproduce functionality that already exists in the WordPress core, or (c) Create a site you do not intend to support, or (e) If you're a wordpress beginner.

The primary advantage to working with pods as a DEV, even one who is pretty familiar with WordPress core, is that it can really speed up dev time by making complex applications easier to develop and roll out. There's nothing that I can't do with WP core functions. But when it can be done via pods in a fraction of the time, and with the performance and usability advantages, it very often makes sense to do so.

The other major advantage for developers, in my experience, is the Templating system which allows for a MVC-like separation of code and markup. I often work on projects with designers who know little or nothing about php. With pods, they can edit templates at the same time that I'm editing php code and there's no worry about them screwing the site up. And they love being able to easily access and edit HTML without having to weed through all the PHP in WordPress templates. So pods has been useful in that respect as well.

Those are just my initial thoughts.

I think the major criticism you are going to get is "why use another system if you can do it with WordPress core." But you could ask the same question of any coding framework. Why use Codeigniter if you could do it with raw PHP? Because the framework provides a level of functionality that allows you to do your job faster, thus making better sites and, hopefully, more money.

In fact, I think that's a good analogy, I think Pods, if it's going to be successful, has to think of itself as THE WordPress dev framework which means it should add functionality that makes WP Core easier to manage and not just work around.

I'm not sure front end users should really care about this question. And Pods 2.0 I think is going to make it irrelevant to them ... hopefully.

bump anyone else ?