Apex Enterprise Patterns: Should UOW only be used with a DML transaction?

Patterns are tools, and like tools, there's no point in using a tool if you don't understand its purpose; it can easily cause more harm than good. Similarly, there's no point in using a tool if it's not necessary. Using a pattern is simply a waste of time and resources when it's not necessary.

As a simple example, you buy a case of twist-top bottles that contain a beverage of your choice. Your two choices are "twist off the top" or "find a bottle opener to pop off the cap." Yes, you can use the bottle opener to open it, and sometimes those pesky twist tops are not as easy to open as they claim to be, but your first instinct should be to just try it by hand. It can save you the effort of finding that bottle opener.

This is what is often referred to as "KISS" (Keep It Simple, Stupid). So, to answer the obviously most important question:

is a UOW necessary?

Nope. UOW is never necessary. There is a point where UOW makes a given task easier, but there's also overhead, so there's a minimum amount of work required before UOW is even worth it. If you're just inserting a list of accounts, no UOW is needed. If you're inserting five layers worth of objects, UOW will typically save you a considerable amount of code.

But, in answer to the original question:

If the Service uses ... and then maps them together to return back to the method requesting the service, is a UOW necessary?

Nope. UOW is strictly about transaction control. There's no transaction, so there's nothing to control.

Should any of this mapping logic be included in the domain layer?

Maybe. Domain Layer, like other patterns, has a purpose. That is to consolidate common domain operations in to a single class. If the entire domain is this single mapping, then obviously you're wasting effort by designing a Domain Layer. If your Domain Layer includes other tools for working with the domain, like populating field values, validations, retrieving complicated data structures, etc, then the Domain Layer is probably a good idea. You would not ordinarily use a Domain Layer just for a single service.

Should the API be responsible for converting the List or Map returned from such services to a Data Transfer Object (DTO)?

Use a DTO only if necessary. A List or a Map is arguably a type of DTO in and of itself, so there's no particular reason to convert from one type of DTO to another unless it makes sense in your API. The client using your API won't know if you're using a Map or a List versus using a DTO, so most of the time, you're just adding overhead. However, you may need a DTO if you need to massage the data to conform to an API specification, so the answer is "maybe, but probably not."