In most designs I've seen for projects like this, the "custom IO breakout host board" isn't really
just a breakout board — it has a lot of bus controller chips of its own, because most modern bus protocols are just too fast/expensive to be run over GPIO pins. These extra chips usually raise the BOM past the point where it's worth it to build such a system; as at that point it's cheaper to just source old x86 parts (controller chips,
sometimes CPU as well) from e-waste.
You want as much of that "motherboard logic" to be handled internal to the SoC as possible. Ideally, the board should only have the one SoC chip on it, plus jellybean parts and passives, plus ports and slots.
Also, let's lean on your example of video for a moment: "running an emulator full screen" isn't nearly the same thing as emulating the host busses — in that it results in the host describing that screen down its own SoC pins using something like HDMI. Whereas we don't even necessarily want a precomposed description of the screen on a signal line.
Remember, we're emulating the CPU and motherboard (and RAM, just because it's impractical not to) inside the SoC — but video support isn't actually an inherent part of an x86 motherboard. OEMs might integrate support for it onto a motherboard — but that "support" is just an embedded PCI-bus device, not some separate VGA bus.
Perhaps the system this board would revitalize, does something special with the communicated changes to the video data, such that pre-composed VGA (let alone HDMI) wouldn't solve the problem. For example, what if the system uses a custom PCI video card, that takes its VRAM and renders it out each frame, by compositing it together with another input video signal (ala the "video toasters" of the era)?
The only way to make that kind of thing work, is to emulate the PCI bus such that you can just plug the custom video card into one of the board's PCI sockets, and the emulated system will pick it up and use it.