On a product development standpoint, I would like to get a general consensus from everyone on the most common and preferred communication methods in the field. Thanks in advance!

In a most general sense, it would be Modbus -RTU on RS-485 if in case I am right in assuming that you are making a instrument for the industrial sector. Across most countries in the world, most small and big manufacturers of electronic instruments provide this. It is an open protocol and easily implemented into your microcontroller. RS-485 has the advantage of being multi-drop, in addition to being compatible to RS-422 devices. If you are targeting PLCs as masters for your product, Modbus on RS-485.
These days, there is increasing use of Modbus over the ethernet physical layer.In case the data volume is quite less than a few hundreds of memory bytes, you don't need ethernet really Ethernet to RS-485 controllers such as the ones made by MOXA are quite inexpensive. Please lookup Modbus.org

You could add a DeviceNet flavour to your product, if you are in the Allen-Bradley ecosystem where your products intermingle with theirs on the shop-floor. Same idea goes for the Profibus /profisafe/Profinet protocol& Siemens ecosystem. For DeviceNet licensing lookup ODVA.org

If your product wants to communicate only 'bits' of data it is the ASI protocol. This is quite common in the machine-tool world.Ref. ASI.org

If you are selling to the DCS world, try and incorporate HART. But this is a far more sophisticated exercise

If you are making a lab instrument, merely to display data/few pages on your own Visual Basic/VC++ application then pure and simple ASCII on RS-232/USB will suffice. To implement this, ref the book 'Serial port complete' by Jan Axelson

Last but not the least, must not fail to mention the CANopen protocol. It has terrific speed plus a number of advanced features. It is also used by small-scale device manufacturers even in India.

For wireless links use Zigbee!

there is no end to this subject. I hope I've given you enough leads to get started.

I think as Raj pointed out, there is no "one size fits all". There are sensor/actuator level (bits) protocols, device/field bus level (byte/word) protocols, control level protocols, and information level protocols. I think that one can safely say at the information, control, and perhaps now even into the device level that Ethernet based protocols are the most popular, for a variety of reasons (no shortage of info out there on that). Some of the most popular Ethernet based protocols in our space are Modbus-TCP and EtherNet/IP.

i believe the communication protocol should be decided on the basis of the field of application of the device your are developing
for example if it is field device [ industry oriented ] you can for profibus cable and protocol, while if it is a digital display device near to operator station
then rs485/mod bus/rs232 is sufficient
but now a days industrial Ethernet/WiFi is coming common
since industrial Ethernet cable is good, and Ethernet protocol is worldwide accepted and cheap , i personally suggest it

Are you developing a new device/instrument/piece of equipment, and you need to implement communications, say, like a temperature controller, or a servo drive, or an indicator-transmitter? Or does your application involve an architecture of off-the-shelf / existing devices/instruments/pieces of equipment, linked to controller(s), like a Distributed Control System?
(1) In the former case, it is worth to check AnyBus (www.anybus.com), depending of the actual device control data exchange needs, complexity, hardware/software capabilities, and budget. Since this is a plug-in board/module, you may be able to replace it with a simpler interface (analog + digital IOs), for lower price alternatives.
(2) In the latter case, your approach is limited by the given devices capabilities - i.e. you will have to adjust your project to what the devices provide. You will certainly end up with a bunch of different protocol adapters in your DCS (or controller). It is important to observe the maximum load on each adapter/bus, as well as the task slice these communications tasks "eat" up from the CPU and its internal bus. A carefully planned, structured, architecture, will spare you many problems.
(3) The HART communications is emerging, for indicator-transmitter equipped instrumentation. On the physical layer, this super-imposes a digitally-modulated signal on the device's 4..20mA analog output. For now, the HART adapters for controllers/DCS are a novelty, so more expensive, and not every PLC maker has them. If you have an array of sensors connected to the same indicator-transmitter, however, using HART as a single communication line may be less expensive than using individual analog points for each sensor.
(4) Finally, a caveat for Ethernet-based protocols. Physically separate the controller's Ethernet from the Company's Local Area Network. If you need to connect via the Company's LAN, say to a remote HMI/SCADA station, always use a ROUTER, instead of a switch. A few bucks will avoid major headaches. Some colleagues will disagree on this point....
Good luck, and let us know of your progress.