Reasonable enough. The article focuses on client-side programs, especially Android, which have somewhat different requirements than the Posix model envisions. Most of the things you need to do on headless servers can be done through the Posix model.
The big weaknesses in Posix they point out are in interprocess communication and parallelism. Both were afterthoughts in UNIX.
UNIX/Linux land never had a good IPC mechanism. (As a former QNX user, I've seen this done right; check out MsgSend/MsgRecv there.) Posix thread-level locking primitives tend to be too slow, but that's partly a hardware support problem. Async I/O now seems to be popular; networks are so slow on mobile, and servers have scaled to the point that dispatching overhead for all the running threads gets to be a problem.
Yes, Posix doesn't do graphics. That's good; if it had a window API, everybody would be complaining about it. Look at the KDE/Gnome wars, or the OpenGL/Direct-X wars.
Here's what I'd change in Posix.
On the file system front, I occasionally argue that UNIX/Linux/Posix file system semantics should be slightly different. There should be several types of files. "Unit files", the normal case, can only be changed in their entirety. Opening a unit file for writing should create a new file, and on successful close (not program exit, abort, or system crash) the new version replaces the old version for future opens. Today, you still have to jump through hoops to do atomic file replace, and the hoops are different for different OSs. Posix doesn't address this. This is something that should Just Work as the default file semantics.
"Log files" should just extend. This is what opening for append should do. You can't go back and overwrite. On an abort or system crash, the end of the file should be at the end of some recent write, and correct out to the last byte of the file length. Logging may be behind after a crash, but should never trail off into garbage.
"Managed files" are for databases. You would get two async I/O completions - one when the OS has accepted the write, and one when it's safely committed to disk/flash. Rather than flushing, database programs would usually wait for the commit completion. This would be a special mode asked for with an "ioctl" call, used only by the few programs that really care about database recovery. The database people would love to have well-defined semantics like this.
"Temp" files (in /tmp or some designated directory) would have only the guarantee that after a crash, they're gone.
On the interprocess communication front, I'd copy MsgSend, MsgRecv, and MsgReply from QNX. That's subroutine-call type IPC; send a message and wait for a reply back. This is what you usually
want for multi-process programs. Connection setup could be improved over QNX; the mechanism for finding the receive port in another process needs to be improved and there should be at least one well-known port number (like stdin/stdout/stderr are 0,1, and 2) that each process uses first. This needs to be integrated with the CPU dispatcher, as it is in QNX, so that when you do a MsgSend, the sending thread blocks and the receiving thread unblocks without going through the scheduler. Otherwise, you go to the back of the line for the CPU on each interprocess call.