Update: Palle Due's helpful answer offers the best solution.
This answer may still be of interest for contrasting member-access enumeration with pipeline use, a discussion of output formatting, and contrasting Out-File with Set-Content.
In PSv3+ you can simply use member-access enumeration to extract the .InputObject values:
PS> (Compare-Object (Get-Content old.txt) (Get-Content new.txt)).InputObject
server05
server06
Note:
Member-access enumeration is convenient and fast, but at the expense of memory consumption, which can be a problem with very large collections (not here). The output from Compare-Object must be collected in memory as a whole in an array ([object[]]), and, similarly, the .InputObject property values are returned as an array.
For slower, but memory-friendly streaming (one-by-one processing), use the pipeline with Select-Object -ExpandProperty, as in TobyU's effective solution.
Re saving to a file: piping to Out-File $location (or, more succinctly, using output redirection: > $location) is sufficient - no need for Format-List.
In general, note that the purpose of the Format-* cmdlets is to produce output for display, not for programmatic processing and persistence.
That said, Out-File / > (effectively) uses the Format-* cmdlets behind the scenes to produce a string representation of the input objects, just like the default console output, which is why it's not the right command for persisting arbitrary input objects.
Use of Out-File / > with strings is safe, however, because they are output as-is. By contrast, even numbers are problematic if they have decimal places, because they are stringified with the current culture's decimal separator (e.g., , rather than . in some cultures).
If your input objects are strings, you can alternatively use Set-Content, which is faster than Out-File / >, but the caveat is that in Windows PowerShell the character encoding used by default differs: Out-File / > produces UTF-16LE files by default, whereas Set-Content uses the legacy system locale's "ANSI" code page (typically, a single-byte 8-bit encoding such as Windows-1252).
By contrast, in PowerShell Core both cmdlets produce BOM-less UTF-8.
Note that Set-Content, unlike Out-File, stringifies non-string objects simply by calling the .ToString() method on them.