user47827: This question was asked by various individuals on Telegram.
The spec (BOLT 2) allows for multiple channels between the same two peers:

Note that multiple channels can operate in parallel, as all channel
messages are identified by either a temporary_channel_id (before the
funding transaction is created) or a channel_id (derived from the
funding transaction).

The temporary_channel_id is unique only within a single connection hence implying the possibility of multiple channels per peer/connection.
As far as c-lightning goes, I get the following error when trying to fund a second channel with the same peer:
Peer already CHANNELD_NORMAL

Why doesn't c-lightning follow the spec here?
Update: Core Lightning v0.11.0 (April 2022) introduced support for opening multiple parallel channels to a single peer (channel multiplexing)

user47827: This was answered by Christian Decker on Telegram.

Just because the specification allows something doesn't mean every
implementation has to implement it and support it. In c-lightning's
case it is both an architectural choice (multiplexing multiple
channels onto a TCP connection is not trivial) as well as a conviction
(peer diversity beats doubling down on a single peer with multiple
channels, and avoids the creation of single points of failure). After
all dual funding and splicing give the same abilities as channel
multiplexing with a reduced onchain footprint as well as less
complexity and less load on the gossip network.

Rene Pickhardt added in the comments below:

Parallel channels might also be a challenge for
payment flows. First the computation becomes more expensive and second
the assigned liquidity is artificially split between two separate
channels. Thus one should always prefer dual funding, splicing and
rebalancing over parallel channels


47827: <p>This question was asked by various individuals on Telegram.</p>
<p>The spec (<a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#channel-establishment" rel="nofollow noreferrer">BOLT 2</a>) allows for multiple channels between the same two peers:</p>
<blockquote>
<p>Note that multiple channels can operate in parallel, as all channel
messages are identified by either a <code>temporary_channel_id</code> (before the
funding transaction is created) or a <code>channel_id</code> (derived from the
funding transaction).</p>
</blockquote>
<p>The <code>temporary_channel_id</code> is unique only within a single connection hence implying the possibility of multiple channels per peer/connection.</p>
<p>As far as c-lightning goes, I get the following error when trying to fund a second channel with the same peer:</p>
<pre><code>Peer already CHANNELD_NORMAL
</code></pre>
<p>Why doesn't c-lightning follow the spec here?</p>
<p><strong>Update</strong>: Core Lightning <a href="https://medium.com/blockstream/core-lightning-v0-11-0-channel-multiplexing-a-new-api-and-much-more-5d34df8cfeb5" rel="nofollow noreferrer">v0.11.0</a> (April 2022) introduced support for opening multiple parallel channels to a single peer (channel multiplexing)</p>
 47827: <p>This was answered by Christian Decker on Telegram.</p>
<blockquote>
<p>Just because the specification allows something doesn't mean every
implementation has to implement it and support it. In c-lightning's
case it is both an architectural choice (multiplexing multiple
channels onto a TCP connection is not trivial) as well as a conviction
(peer diversity beats doubling down on a single peer with multiple
channels, and avoids the creation of single points of failure). After
all dual funding and splicing give the same abilities as channel
multiplexing with a reduced onchain footprint as well as less
complexity and less load on the gossip network.</p>
</blockquote>
<p>Rene Pickhardt added in the comments below:</p>
<blockquote>
<p>Parallel channels might also be a challenge for
payment flows. First the computation becomes more expensive and second
the assigned liquidity is artificially split between two separate
channels. Thus one should always prefer dual funding, splicing and
rebalancing over parallel channels</p>
</blockquote>
