There are two totally different things here -- the number of LCs/LEs reflects the amount of logical functionality you can implement -- the process node impacts how fast the device will function (and how much power it will consume).
So you mean that I just have to concern about the number of LEs/LCs, but what if those FPGAs were made with different manufacturing processing, for example, Xilinx Spartan-3 series are made with 90nm processing, and Altera Cyclone series are made with 130nm processing, how do I compare these devices?
PS: Max I reached this article from your Design starts article (http://www.eetimes.com/design/programmable-logic/4214302/What-s-the-number-of-ASIC-versus-FPGA-design-starts-). I noticed you have bug in the cross URL in this article to that above. it crashes due to doubled ref (http://www.eetimes.com/electronics-blogs/other/4210768/%20http://www.eetimes.com/design/programmable-logic/4214302/What-s-the-number-of-ASIC-versus-FPGA-design-starts-)
It is indeed head spinning, I made my PhD on FPGA architectures and always wondered about this strange comparison mystery and used to crush my head when people asked this question :).
It is scientifically insane to compare like that!, particularly with heterogeneity (hard blocks), as you mentioned also.
The near best thing one can really do is take design and dump it on ISE/Quartus...(often doable with no high effort). One will get rough idea which device of that vendor will/if/may best serve needs.
Soon it will be the ASIC guys who start using LUTs instead of ASIC gates as they try and hang on to their shrinking market in a last ditvh effort to capture some of the bigger FPGA market. Won't that be funny...
I agree. Sometimes #LUTs is not the critical resource. Perhaps your design is BRAM or DSP block limited. I recommend vendors quote an FPGA device capability vector e.g. (#LUTs, #BRAM, #DSP, etc.) and/or something more descriptive (#k-LUTs, k, LUT delay, #LUT-RAM, LUT-RAM size/#ports, #BRAM, BRAM size/#ports, #DSP, DSP-size, etc.).
See also my old article on this topic, http://www.fpgacpu.org/#021129.