fopen, fclose, et al are function calls -- they jump your program to a location in memory and execute the code there. If you ran the program in a debugger, you could potentially trace inside these functions and see what they do. They are built for reasons of convenience and portability -- you could build a function which works the same everywhere, for instance, even when the system calls might be slightly different, or add simple functionality like buffers, which is indeed what stdio calls like fwrite are for. It's faster to call putc() 10,000 times to write single chars than to call write() 10,000 times for single chars because putc will just dump it in memory for later.

They certainly can't replace system calls. To write to a file, fwrite() must ultimately call write().

System calls on the other hand are not libraries. They don't jump to the start of an instruction in memory, they pass a message to the operating system, then wait. If you try and trace inside a system call, there's nothing to trace, because your program literally stops running while the system call happens -- the action happens inside the kernel itself, where you can't see.

C is able to freely use raw system calls because it can understand the same data structures the kernel uses for system calls -- the kernel is also C. It compiles it down into raw assembly language like everything else; it becomes the setting of a few registers then something like INT 0x80 to make a software interrupt to inform the kernel you want a system call.

This is difficult for other languages to do natively. Surely they can do INT 0x80, but without the C language itself, it's very difficult to get the data structures right. I've seen some people hardcode system calls in perl and have their code stop working when they move it to a different system, because the data structures changed, but their code didn't. In C, you'd just use the native data structures for wherever you were, and your code wouldn't need to change.