Not sure why your fighting me on this, but here it goes:
We are talking about two things.  One is the message size and RAM, and
second is the app design and using SB.

- Message size
a) When would it ever make sense to send one big message (say over 5MB)
instead of chunking it?  Almost never IMO.
b) first it takes up huge amount of server RAM - which does not scale.
c) you can't write out any data until you receive the whole message, so your
wasting disk IO you could be doing.
d) If you fail half way into the large message, you have to start the whole
message over again.

- App design / protocol
a) I can think of many ways to do this without SB, but SB seems perfect.
b) I have a stream solution too using varbinary(max) column here:
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!404.entry
but that is not what I am talking about.  The file could go to DB or disk -
I don't want to get hung up on that point for this.
c) sure you can get ftp to work, but it is not clean and you have to play in
two ball fields all the time.  You have multiple open ports and you have two
separate security channels that you probably need to sync somehow.  You need
a message channel and have security and encryption on that, and you have an
ftp/data channel that has separate security (and the two don't talk to each
other).  And if you want security and encryption, you have to get SFTP and
require clients have it too.
d) As I said, Indigo and WSE are not a good fit yet for streaming large data
because of the MTOM issues.  Sure we can use sockets and create a custom
solution, but now we are back to doing everything yourself (security,
reliable, encryption, etc.)

So SB allows both your binary data (in this case) and your message channel
to be neatly in the same message stream and programming in .Net on both
sides.  You can send some xml message to start the request, and then flow
messages back and forth as needed.  So all your logic can stay in your SP
and supporting classes.  You also need only one inbound port, and it works
via NATs, etc, as the client starts the dialog and it is TCP based.  You got
integrated security in *one spot and can use custom table security and/or
Windows security.  You can use encryption.  You can compress your messages
with little effort in-stream.  You have ready access to all table data to
log auding, history, credits/debits, state, email, etc.  It handles the
retries for me.  I mean it is darn near perfect.  I can do all this in one
place and have a discreet client and server model without have to integrate
a bunch of other tech such as ftp or sockets or wse, etc.  Am I wrong?

Right, if I am only sending 41KB of data it does not matter much.  Worse
case is two messages.  But if I set my stream chunk size to 41KB and need to
send 100 messages (to represent the whole stream), that turns into 100 40KB
messages and 100 1KB messages - double the number of messages needlessly.
That is why you need to know the chunk size so you can send <= 40KB per
message (or some multiple of the message chunk size).  The last message in
the stream will always be <= buffer size.