OK. Implemented 16-bit and 32-bit memory writes as well, but somehow Windows 95 RTM stops booting properly(with a triple fault or weird function call before more bugfixes) when 16-bit and 32-bit writes actually report it's writing 16-bits or 32-bits? The write writing 16-bit or 32-bit values to RAM doesn't seem to affect this directly, but it seems to have something to do with the caller seeing 16-bit or 32-bit data having been written? Hmmm...
Edit: Hmmm... So any of the write optimizations being enabled(16-bit and/or 32-bit) causes Windows 95 to crash. The 16-bit enabled but the 32-bit disabled causes some VXD call error, while enabling them both causes it to triple fault?

OK. Eventually seemed to have found the issue: some paging-specific writes by the CPU internal routines that bypassed the BIU required it to use the BIU for it's reads/writes instead. That was used by pretty much all CPU routines that don't use the BIU request/answer system(so that's basically all protected mode functionality itself: descriptor reads/writes and all TSS reads/writes).

After changing said byte read/write routines to use the BIU read/write routine(which the BIU applies all it's caches) instead of bypassing it entirely(including the A20 line and CPU-specific wrapping(24-bits/20-bits wrap), now using the same function for all CPU reads/writes(the BIU cached one), everything works correctly again(noticed it once I restarted Windows 95 RTM setup's graphical part(directly after unpacking MINI.CAB) hanging(failed to start protected mode properly itself).

Just managed to improve hard disk/CD-ROM responsiveness. Now, instead of constantly updating the HDD/CD-ROM LEDs on the display(the C/D/E/F leds that can become green (hard disk/CD-ROM disk read or active floppy drive motor) or orange (hard disk writing or CD-ROM having an ejected drive tray) now are using reduced checks for updating the LEDs.
Instead of updating the LEDs and display text layers constantly when the drive changes said LED state(to off(0)/on(1)/orange(2)), it will now use a simple time-based algorithm when rendering it.
Now, the GPU code renders the display at 60FPS always(seperated from the system emulation itself, although in the same thread). It will simply tick those LEDs off based on the rendering framerate(which is as constant as possible 60FPS). Now, every frame it will update the LED state based on it's current LED state(0/1/2) and the buffered LED state(0/1/2). The higher of the two becomes the new LED state for the remainder of the period. The end of the period is determined by a frame rendering counter that's used after the rendering of the screen(based on the active LED state) is complete. After each 6 frames(thus resulting in a 10 FPS update rate for the LEDs to clear), it will clear the active LED status, allowing it to be repopulated by the beforementioned LED state checking code each frame.
And during said checking of the LEDs, the higher value wins and becomes the new LED state to use(at least until the 10FPS frame timer expires). So if the first frame(frame #0) sets it to green and immediately clears it on the next frame(frame #1), but sets it on the frame after that(frame #2) and clears it on the next frame(frame #3) and stays off until frame #6, the LED will in effect turn on at frame #0 until frame #6, where on frame #7 it will turn off, effectively causing the LED to update no more than 10 times a second(10 x 6 = 60FPS, which is the framerate).
And during said period of 6 frames being rendered, the higher value can still override the LED color(from green(1) to orange(2). So that's at most 2 frames being updated each 6 frames, effectively causing it to have a up to 20FPS framerate(for interleaved reads/writes), instead of the previous 60FPS update rate(which caused the CPU emulation to take a big dip in performance due to the text surfaces needing to update their pixels each frame). And disk writes can still be seen, since their color(orange) has priority over the normal green color LED.

Running Creatures on Windows 95 RTM now seems to run at a steady 28/29% speed at 3 MIPS(in IPS clocking mode).