I agree that sbrk/brk are nearly deprecated. But not all allocators I studied use mprotect or mmap. Most reference material (old OS books & blogs) still refer to sbrk/brk and/or malloc when discussing reference counters or garbage collectors. And Linux has a nice gotcha (see the Linux notes here[1]) in its implementation of the sys_brk syscall. It matches neither of the interfaces described for sbrk or brk exactly that most people are familiar with.
For me, however, I have a personal goal to show how to implement the basic newlib porting requirements [2].
A flat address space is the future. You don't need virtual memory when a flat address space can hold all memory addresses for all processes as it does now with 64-bit processors.
Could you explain how virtual memory makes a process more secure? My intuition is that it would be another source of contention to manage (like CPU, RAM, IO, etc).
Maybe you're considering non-sequential address space an improvement for security. That I could see. ASLR would be another, which, you can see the effect of by multiple runs of t/_end.exe in rt0.
For me, however, I have a personal goal to show how to implement the basic newlib porting requirements [2].
[1] http://linux.die.net/man/2/brk
[2] http://wiki.osdev.org/Porting_Newlib