I looked at a portal, but because this shows Address1, Address2, City etc left to right, it's not intuitive to the user because every time an address is shown on any system, it's line by line.
What you describe is the default format to a portal, but it's not your only option. You can use portal set up to decrease the number of portal rows and then increase the height of each portal row by clicking the portal and dragging a resize handle. Once you have resized the portal row to the size you want, you can then re-position your address fields within the portal row to get the format that you want here. This can then become much like a "mini form view" instead of the default "mini-table view" typical of most portals.
Design Note: When I need to do this, I usually set my number of portal rows to 1, redesign my portal row as needed and then return to portal set up to change the number of portal rows to the number that will fit the available space on my layout.
Still working with this and I think it comes down to layout design rather than technique at this early stage. In your experience what is the best way to accommodate and display 11 (worst case in my world!) addresses against a single customer?
There's no one simple answer. Much will depend on a) the display hardware: 1 monitor? 2 monitors? 1 laptop w/smaller screen? iPad? iPhone?
Much will depend on what else needs to be displayed in addition to the list of Addresses on your screen.
And what you need to do with this info is also a factor, you may need to edit the data or maybe you just need a read-only display.
So my main recommendation is to take a careful look at all the different requirements you need to meet for your layout and then experiment to find the best approach that you and your users are happy with.
In general you have the following options for simultaneously displaying the data from multiple records:
1) Table View--not the most user friendly, I prefer table view as a "Developer debug tool" rather than for general use, but you can put data from a parent record into a header or a footer.
2) List View--Good all around choice, lots of layout design options, but much more work to set up than table view and doesn't have some of the flexible view options of a table view. If you need to display additional data from a parent record, (or even multiple parent records), this option has some limitations, but you can include such data in a header footer, leading or trailing grand summary layout part or in a sub summary layout part. Note that this limits data from a parent record to locations that will be outside of the body layout part unless you want the same parent data repeated over and over for every listed address record.
3) Portal--this allows you to take any size rectangular region of your layout and make it a "miniature layout" referencing a different related table listing from one to potentially an unlimited number of records. This gives you lots of options for including data from a parent record not possible in the preceding two options as you can put the parent data to the left or right of the listed addresses as well as the above/below options for the previous two approaches. And you aren't limited to a single portal. You can put several portals side by side, each set to display a different range of portal rows or with portal filters (or filtering match fields) that put different sub categories (such as shipping, mailing, billing addresses) into different portals.
And then you have a variety of options that let you break up this data into sub sets, and view just one sub set at a time. You can put several portals on your layout, for example and put each one on a different pane of a tab or slide control. You can hide a portal inside a popover and then only take up screen space to view it when you click (or tap) the popover button. The portal itself can have a filtering control field where you enter or select data that limits the records shown to just specific records from the group of related records linked to your current parent record. (A similar control can be put in a header or footer to filter records in a list or table view.)
4) And you can use a large multiple row field--almost always a calculation field, to list the contents of multiple records in a single field. This field would in many cases be equipped with a scroll bar to enable it to display more data than it could without that scroll bar. A calculation using the List or ExecuteSQL() function is typically used to produce such a list. This approach essentially produces a "read only" view of your data as you can't really edit the data directly in the field (not 100% impossible if you use a script to put the data in a regular text field, but saving any changes back to the original records would be difficult). But while it can't be edited, the resulting list of data can adapt in terms of how many rows of text are used for a given address, closing up unneeded space--such as addresses that need an extra line of text vs. those that don't.
And except for being "read only", this last option has all the different possibilities of a portal so you can put such a field inside tab controls, popovers etc.
And for all of these methods, you can also use an extra window such as a floating document window to pop up such a view of your addresses on demand by clicking a button and the window can be sized to fit your needs. The script can even expand or contract the height of the window to fit the number of records listed in it to fit the number of related addresses.