Let me start this post by saying: I hope someone tells me that I am wrong.From what I am reading, these custom fields appear to be a step back words from Product Types.

I was using the Cherry Picker Module that provided a great filter for Product Types. That developer did a good job of outlining the draw backs of this new Custom Field replacing the Product Types.
http://www.galt.md/index.php?option=com_blog&a=74&Itemid=82 I am most concerned with ease of set up and most importantly
performance, as the site I am managing has over 140,000 items.
This is a quote from the link above that provides insight as to why this is a step back words.
PerformancePerformance may be a great issue especially for those who have large amount of products.
Let's have a comparative example between Product Type and Custom Fields (we will not delve deep into details).
Let us say, we have 2,000 products and 2 Product Types, each has 1,000 products. And each Product Type has 5 Parameters (like: Brand, Screen, Ram, Hdd, OS).
In Virtuemart 1.1 this would be represented in Database with 2 tables: "vm_product_type_1" and "vm_product_type_2" with 6 columns in each: first column is "product_id" and rest five for each parameter.
Naturally, each of two tables would have 1,000 records.
And when performing a search MySQL will look up only among 1,000 records.
Now let's see how Custom Fields would store 2,000 products' filters in Database.
All values are stored in one table "virtuemart_product_customfields". Every Parameter is being inserted as new record, so one product with our 5 parameters will have 6 records: 5 records for parameters plus 1 record for parent-custom-field (the one that stores 5 custom fields as children).
So our 2,000 products will end up as 12,000 records.
Now, from a logical point of view, in which case 50* SQL queries will perform better (look up from 1K or 12K of records)?

* - It's just an example for 50 filters that make 50 queries.

:'