Not in all cases the schematics, parts lists, board views or even ROM assembly listings are "leaked" - it was quite common until into the 1980s to ship (or offer as an addon product) full documentation of that kind with professional electronics (which many computers were categorized and priced as) and also sometimes with consumer electronics. Existing copies of these might or might not have been copied with the publisher's consent, but they were available to the general public.
IIRC, So called "technical reference manuals" were available for ISA based IBM PCs (not MCA based ones, though detailed "maintenance manual"s exist) and 8-Bit Apples.
Mainboards and extension cards in the 1980s and 1990s commonly had schematics in the included documentation.
Often, so called "leaked" material, while never intended for the general public, was originally marketed to the washed masses (professional repair workshops and developers).
Also, programming books from that era (eg books on EGA/VGA or PC assembly programming) commonly describe things in register-level detail - which was needed if there was no sufficiently capable device driver included in your OS or programming environment!).
Look for the documentation coming with early implementations of a standard: These often assumed that the user had no documentation about the standard that they could be referred to... For example, printers using the parallel interface still sometimes found today in old or niche devices existed a decade(!) before PCs, and 1970s manuals would assume that the poor user that just unpacked the printer will now have to write a device driver or even design an interface board.
On a sidenote, it was not rare to find the schematic papers inside the case in a pouch or similar 1970s/1980s TVs (have found such in a curbside find Philips K11 or K12 TV which I stripped for parts ages ago, whoever put them there...)...
Even today, for CPUs as well as peripheral and memory chips datasheets¹ are commonly available online, either from the manufacturer or from online datasheet archives. These will either contain instructions on how to program them or refer to further manuals (eg if there is an embedded CPU core, they will commonly refer to the pertinent CPU/architecture manual).
The biggest problem in understanding hardware architecture from existing hardware and/or schematics are programmable (Flash, OTP, external, mask ROM...) parts that do not allow reading back and/or interpreting the code. Examples:
microcontrollers with a protect bit set - if they can be overwritten, that is often only as a whole, if you want to overwrite the protect bit you overwrite the content!
PALs/GALs/CPLDs... that actually have the "result" of code and not the code itself stored in them - think of these as parts that you can rewire at will via some coded input from a programming device, and they do not allow you to read back the rewiring instructions - and what is in them can be stateful with some devices and so cannot reliably be analyzed by just measuring out truth tables.
Devices that will be fed code from an external memory (sometimes stored in ROM or mass storage and uploaded via an init routine from some CPU) that is in a non-source, undocumented format: RAM based FPGAs, for example.
Parts that are INTENTIONALLY made hard to reverse engineer, eg modules that are potted and/or outfitted with self-erase/self-destruct devices (crypto hardware)...
ASICs and gate arrays - the hardwired version of PAL/GAL/CPLD
Application specific chips that have a whole, programmed computer system inside, which is documented only at a functional level (no one except the manufacturer of that chip has the code in that ROM). The PS/2 keyboard controller in a modern PC would be such a thing - a deeply embedded MCS48 or MCS51 with ROM and all, though the code might be very similar to what is in an actual dedicated keyboard controller chip.
¹ The "datasheet" is a type of formal documentation when it comes to electronic parts, very different from the use of "datasheet" for marketing brochures!