The difference between the render-to-texture and framebuffer effects on the N64 and on a PC is that on the N64 the RDP (the N64's GPU) and CPU share the same RAM, so the CPU has full access to whatever the RDP is doing, plus the RDP can be told to use any address for the framebuffer. This allows a game to tell the RDP to render a scene, then the CPU can take that, modify it however it wants, and use it as a texture, blend it with a previous frame, change the color, blur it, the possibilities are endless because the CPU has full access to it.
On the PC, the CPU and GPU have completely seperate areas of RAM. Render-to-texture works by instructing the GPU to render to an area of VRAM other than the frame-buffer, and then use that as a texture in future rendering. The CPU has no part it in. Special effects, such as motion blur, can be acheived through advanced blending, and vertex and pixels shaders, but it is still limited by the capibilities of the GPU.
The problem with emulating framebuffer effects comes when the game's code wants to modify the contents of it...we can't emulate the game code on a GPU, so the CPU has to do it, but the framebuffer isn't directly accessible by the CPU as it is on the N64. This means we have to copy it from VRAM to RAM, let the game code modify it, and then copy it back, an extremely slow process.
glN64 partially works around this problem by trying to keep everything on the GPU, but this only works for render-to-texture effects, and doesn't allow for any modifications to the framebuffer's contents.
The next version of 1964 tries to remedy this problem by notifying the video plugin when the CPU is trying to access the framebuffer, so the plugin can copy the framebuffer to and from system RAM only when needed, this helps out alot, but isn't perfect.
I hope that sorta sums up the situation, it kinda got a little long-winded...