For me, the more important aspect is whether all the options you are considering are matched in time resolution (samples/s) and in amplitude resolution (number of bits, amplitude range) to properly respond over the intended application.

Analog sensors/devices have different bandwidths depending on the physical principle being used - you cannot compare them without specifying the SR discrete vs bandwidth analog, against your experimental needs and cost

Thank you Prof. Galiana. 

Indeed I had overlooked that information while posting the question. My bad.!

The data acquisition/updation (read/write) rates will not be more than 100 samples/second, and 12/14 bit resolution should be fine with me. In fact, I will be logging (to hard disc) only twice per second. 

Regards.

Be careful - You are logging to disk at 2samples/s? That is a 2Hz A/D sampling rate, which means the data coming in would have to contain a maximal bandwidth of 0.2-0.4Hz to be sampled accurately especially for control situations (the nyquist rate is not enough to track a signal, it simply avoids aliasing). You need to consider the BW of your system, and the bandwidth of the input to select a sampling rate. The required number of bits depends on the amplitude range of inputs and the gain changes caused by the system dynamics (Bode gain) i.e. the range of outputs is the cascade of the range of input amplitudes (min,max) multiplied by the range of gain over the frquency band of interest. You have to be able to resolve signals well over the whole range, otherwise you will have discretization noise that cannot be filtered out after the fact, since it has a bandwidth down to DC.

Comparison is difficult because it depends on the specific application. In case of realization of PID in Lab-view or MATLAB 'Derivative' part needs special care. Derivative samples should be slower that the Data-acquisition card. The controller generated output in case of PID in Lab-view or MATLAB needs to go the hardware through an S/H operation. Which may give signal spikes to actuator. Hence the control signal needs to be filtered by an analog low pass filter which are generally embedded with the Data-acquisition cards now-a-days. The filter will delay the signal. So if the system dynamics is faster like inverted pendulum or Magnetic levitation system,  it may create problem........Design issues do not matter much but the implementation issues will matter specific to application in options (1), (2), (3), 

If it is for a laboratory set-up then I would go the Matlab/labview way.

The simple reason is that it would allow you to implement more advanced control algorithms than just a PID.

With a hardware PID, you can operate the "plant" without the need for a computer which is safer but less flexible.

Thank you Prof. Galiana, Mr. Rubillon and Mr. Roy.

My application is merely to make a temperature controlled electrical-measurements setup. So basically, its not going to a a transient acquisition/control/measurement. I will ensure the desired temperature has reached (and held for a minute or so, during which the electrical measurements will be analysed and logged) and then ramped to a new value. So I need not even "log" the entire T vs time data in real time to use less system resources. I understand this method to be quite naive and slow.

You suggestions and opinions are definitely worth evaluating.

@ Prof. Galiana,

I had said I would acquire 100 samples/second (or more) for the control part, but I will average the data to 2/4 data points per second for logging, to minimise system resources. Getting the precise temperature control is more important than getting the precise temperature profile. Finally what I want is some property vs temp data. So i need to know the exact temp data corresponding to the property measurement (of course I will have to use "simultaneous" data logging). I plan to use minimum of baud rate of 9600 bits/s.

You might only be interested in precise temperature control but you also mentioned ramp-soak temperature profiles in your initial query.

I would still use Matlab/Simulink for the sheer flexibility of the set-up. Also you will be able to "play" with different control strategies which you wouldn't necessarily be able to do with a hardware PID controller.

Another solution might be to use a PLC to do the control of the rig and provide a software interface to Matlab for more advanced control algorithms before implementing them in the PLC itself.

More food for thought...