TTL and RS232 are mutually exclusive (although you can easily convert from one to the other). I think you are switching around UART and RS232. UART is timings, bit order, numbers of bits, etc., but not voltages. RS232 adds voltages, connectors and pinouts, etc on top of UART. It is one of many physical manifestations of UART communication. TTL is another physical manifestation of the UART protocol, and is often used chip to chip. (There is technically nothing RS232 on the Arduino - I don't think I've ever heard of a micro that actually works with RS232 levels) There are several reasons for using a USB-UART or USB-RS232 chipsets/circuits:
Legacy hardware and entrenched design preferences: Industrial automation and other types of ruggedized electronics like to use RS232 and other tried-and-tested communications methods, especially when speed is often not a serious limitation. RS232/UART are also much easier to electrically isolate than USB for safety when working with line voltage devices.
Direct USB is more involved to implement as a device, and much more involved to implement as a host. If I design an RS232 device, anyone else can design something that works with it quite easily. This is true of both PC hosts and micro-based hosts. RS232 is much simpler in both cases.
You can communicate to some VERY small micros using UART, but the smaller 50% (give or take) of micros don't have USB support. Also, you can hit pause on your debugger while using UART without Windows killing communication on your device :)
As for the Arduino baud rate, it is confusing. This has no effect on the communication between the computer and the USB-UART chip (FTDI, etc). This is not UART communication, but a USB-CDC class to emulate an RS232 (or other UART) serial port over USB. The baud rate takes effect between this chip and the micro, which is actual 5V (TTL/CMOS) UART communication.
Looking at your photo, you seem to have +Vs of the LM35 connected to +5V on the Arduino, so if you are reading 3.84V there, that is definitely a problem to address before trying to fix anything else.
The likely problem is this: Te 7 segment displays (or some wiring fault on the breadboard) is drawing too much current from the Arduino, and ultimately from the USB connector. This means that the voltage regulation provided by the USB power supply is no longer working effectively, and so the supply voltage that you measured as 3.84V is likely wandering, and in any case low.
While many if not all the chips in this project will operate off voltages lower than the 5V that V+ is supposed to be at, there are some aspects that will be sensitive to lower V+.
One notable V+ -sensitive feature is the A-to-D convertor in the Atmega328. (As The Photon commented.) The convertor can be set to choose between a couple of different reference voltages. Your code indicates that you have it set to use the V+ (VCC) value (5V) as the reference. If that reference is low (eg: 3.8V) then your input voltage from the LM35 will measure as a number that is scaled up accordingly.
And I'm fairly certain that if your V+ is low, it will change according to how many LEDs are illuminated and drawing current, so your measurements will vary according to what digits are displaying, and vice versa, of course.
Once you've fixed the power supply issue, you might assess whether to set the A/D convertor to use the built-in 1.1V reference instead, as this will give you higher resolution and more stable converted values. See the Atmega328 docs for more details on the A/D convertor and options.
Best Answer
It seems as though you're running both the 5V USB and 12V battery through the same linear regulator. Since 5V doesn't have enough excess voltage to regulate to...5V, it is being dropped to 4.5V (per comments in question)
I suspect that you are seeing a change in the ADC reference voltage (AVCC or AREF) that causes the absolute output of the temperature sensor to be interpreted differently.
You should either make better provisions for creating a stable reference voltage, or use the internal 2.56 reference of the ATMega32.