I've held off on doing anything interesting in PRINT for some time now, based on the... fear. 
It's the fear that if we give meaning to parts in the "print dialect", that there will be potential for confusion if we evaluate a freeform expression in the middle of that dialect that uses one of those parts.
>> block: [a b c]
>> print ["The block is: block]
** Error: Unknown rendering for &[block] in DELIMIT
>> print ["The block is:" @block]
The block is [a b c]
>> print ["This is" if get @block ["my fear"]]
This is my fear
There we see @block having nothing to do with molding at all. And yet, there it is--right in the "PRINT dialect"
So what I'm afraid of is that you'll be trying to read a PRINT expression and not knowing when the "magic" dialected parts are going to do their magic, vs. just be a parameter to some function call.
We wouldn't require groups on everything. Just function calls...
>> name: "Roscoe"
>> print ["Your name is" name] ; no parentheses needed
Your name is Roscoe
>> print ["Your backwards name is" (reverse name)] ; need parentheses
Your backwards name is eocsoR
There's an added benefit: if you see something like print ["foo" baz bar], you know baz and bar aren't functions. They have to resolve to non-function values, so you can read that with more confidence as to what's going on.
But Is The Fear Justified? Or "Trust The User"?
The only mechanical problem with mixing dialected-interpreted values with code is that it screws with enfix. Because the dialect is going one item at a time--consuming types that it recognizes--and then calling out to the evaluator when it sees things it doesn't--it could consume an item that people thought was meant for the left hand side of a function. That's not the end of the world.
I dunno. Beyond just the fear of confusion, we could also open up dialecting for paths and chains. I feel like there's a lot of cool things we can do with PRINT and giving meanings to things...
>> string: "abcdef"
>> print ["What about limiting prints?" string:3]
== What about limiting prints? abc
So how oppressive would it really be if any function calls in PRINT were in GROUP!s?
Dialect With Fear, Or Dialect Without Fear, But... Dialect
You'll have a hard time convincing people your "dialected" language is all that when C's printf() is kicking your butt in the features department. So we're way behind schedule on having a featured PRINT with intelligent formatting as a dialect.
My instincts say that using GROUP!s for function calls isn't that oppressive, and cleans up some edge cases like enfix meddling with the code. When I have complex expressions in PRINT I usually parenthesize them anyway.
So I'm eyeing the concept of requiring the groups.