This strikes me as something that shouldn't matter in the vast majority of applications. Putting a bunch of logic for rendering an application-specific format of your data in prepared statements or stored procedures in your database violates the separation of concerns that most folks like to maintain between the layers of an application.
The difference in string concatenation performance is unlikely to be a significant proportion of total request latency unless you are generating very long strings from very short components very inefficiently (appending in a loop with immutable strings, for example). Otherwise, waiting on disk and network are likely to be a far higher percentage of total request latency than string concatenation. Additionally, it is usually vastly cheaper to scale your application layer horizontally than it is to scale a database, so even if the application logic is slightly slower, it will usually be cheaper to throw more compute horsepower at the application layer if/when latency starts to become a problem unless latency is problematic even when serving only a single request at a time.
Use your database to store data and your application to render the data in an application-specific manner. That way, if you end up with multiple applications requiring different representations, you don't have to accommodate both in your data storage and retrieval layer.
If your rendering code is a significant percentage of total latency, consider caching the rendered results rather than moving the rendering logic into your data storage layer - which is unlikely to be significantly faster, anyway. Most mature languages/environments do basic string manipulation pretty efficiently when left to their own devices.