As far as I remember (unfortunately it's been a while since I touched the code so I may be wrong), SP (similarly to most if not all the other portals) have the "bad habit" of running the blocks code directly "in place" while the page is generated, in other words when the code of a block is executed, anything in the template before that block has already been echo'ed to the buffer.
This approach is for sure the easiest and the one that gives end-users the fastest approach to writing their code in a block: 1) grab stuff, 2) do something, 3) echo anything.
The drawback, it that the way it is now, it's impossible doing some stuff (like adding css to <head>) without hooking the buffer into the block (this is possible, a bit ugly but definitely possible).
To solve this problem (and few others alike), each and every block (php blocks as well, don't forget that because I'll come back on the point later) needs to be composed of two parts: the "code" and the "template". This is the path I'm taking with the changes I did a while ago to the ElkArte port of SP.
It's not a terribly huge task, surely a tedious one, potentially a problematic one for non-tech-savvy users, especially when it comes to php blocks.
Why, you ask?
Obviously because anyone has to adopt the "MVC" mentality of "preparing" all the data needed for the output in a place, and use it in another. Once grasped it's not at all a bad thing, though it's another piece of "junk" to each to people that want to write "a simple php block".
Of course there are alternatives (i.e. run the code before sending out the template, instead of using "echo" build a string and return it) that may be better suited, anyway, changes are needed, and changes that will break any currently existing block (unless you pick up yet another (ugly) path, creating the block "source-side", capture the partial buffer created by the block, clean up the buffer, and return the block output).