That ISO image is only bootable as a (real or virtual) CD-ROM; it does not have the additional structures to make it also appear as a valid bootable hard disk image.
Booting from USB drives on systems with BIOS is normally handled by making the USB drive appear as a hard disk. A hard disk will be BIOS-bootable if it has a valid Master Boot Record (MBR) as its first block.
On the other hand, a CD-ROM is bootable if it contains Eltorito boot headers among its ISO 9660 filesystem extensions... and those extensions are not typically located at the very beginning of the disk, but instead in a location determined by the ISO 9660 filesystem structure.
It is possible to make a .ISO image file that is also parseable as a valid hard disk image, by adding the MBR at the very beginning of the disk and arranging the contents of the ISO9660 filesystem in a way that's also compatible with it. But this is not the default: although most modern Linux ISO installation images are prepared this way, not all of them are.
This specific ISO evidently isn't, as you can dump the first 512 bytes of the ISO image and see it contains only zeroes:
$ dd if=CentOS-7-i386-Minimal-2009.iso bs=512 count=1 | od -t x1z -A x
1+0 records in
1+0 records out
512 bytes copied, 7.6959e-05 s, 6.7 MB/s
000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
*
000200
The first 512 bytes of an ISO image that has been prepared to also be usable as a BIOS-bootable hard disk image will look quite a bit more complex. Example:
$ dd if=/usr/lib/ipxe/ipxe.iso bs=512 count=1 | od -t x1z -A x
1+0 records in
1+0 records out
512 bytes copied, 0.00298604 s, 171 kB/s
000000 33 ed 90 90 90 90 90 90 90 90 90 90 90 90 90 90 >3...............<
000010 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 >................<
000020 33 ed fa 8e d5 bc 00 7c fb fc 66 31 db 66 31 c9 >3......|..f1.f1.<
000030 66 53 66 51 06 57 8e dd 8e c5 52 be 00 7c bf 00 >fSfQ.W....R..|..<
000040 06 b9 00 01 f3 a5 ea 4b 06 00 00 52 b4 41 bb aa >.......K...R.A..<
000050 55 31 c9 30 f6 f9 cd 13 72 16 81 fb 55 aa 75 10 >U1.0....r...U.u.<
000060 83 e1 01 74 0b 66 c7 06 f3 06 b4 42 eb 15 eb 02 >...t.f.....B....<
000070 31 c9 5a 51 b4 08 cd 13 5b 0f b6 c6 40 50 83 e1 >1.ZQ....[...@P..<
000080 3f 51 f7 e1 53 52 50 bb 00 7c b9 04 00 66 a1 b0 >?Q..SRP..|...f..<
000090 07 e8 44 00 0f 82 80 00 66 40 80 c7 02 e2 f2 66 >[email protected]<
0000a0 81 3e 40 7c fb c0 78 70 75 09 fa bc ec 7b ea 44 >.>@|..xpu....{.D<
0000b0 7c 00 00 e8 83 00 69 73 6f 6c 69 6e 75 78 2e 62 >|.....isolinux.b<
0000c0 69 6e 20 6d 69 73 73 69 6e 67 20 6f 72 20 63 6f >in missing or co<
0000d0 72 72 75 70 74 2e 0d 0a 66 60 66 31 d2 66 03 06 >rrupt...f`f1.f..<
0000e0 f8 7b 66 13 16 fc 7b 66 52 66 50 06 53 6a 01 6a >.{f...{fRfP.Sj.j<
0000f0 10 89 e6 66 f7 36 e8 7b c0 e4 06 88 e1 88 c5 92 >...f.6.{........<
000100 f6 36 ee 7b 88 c6 08 e1 41 b8 01 02 8a 16 f2 7b >.6.{....A......{<
000110 cd 13 8d 64 10 66 61 c3 e8 1e 00 4f 70 65 72 61 >...d.fa....Opera<
000120 74 69 6e 67 20 73 79 73 74 65 6d 20 6c 6f 61 64 >ting system load<
000130 20 65 72 72 6f 72 2e 0d 0a 5e ac b4 0e 8a 3e 62 > error...^....>b<
000140 04 b3 07 cd 10 3c 0a 75 f1 cd 18 f4 eb fd 00 00 >.....<.u........<
000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
*
0001b0 48 07 00 00 00 00 00 00 c4 7a ef 12 00 00 80 00 >H........z......<
0001c0 01 00 17 3f 20 01 00 00 00 00 00 10 00 00 00 00 >...? ...........<
0001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................<
*
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa >..............U.<
000200
The first part is the boot code within the MBR (in this case, it's apparently using ISOLINUX from the SYSLINUX family of bootloaders, which makes sense as the filesystem type within the main part of the disk image will be ISO9660), then the actual MBR partition table, and the two last bytes contain the 0x55 0xaa signature bytes.
Why have the CentOS distribution builders omitted this ISO image preparation step in this specifc case? Only they themselves might know: perhaps it's a mistake, and someone has just forgotten to include it in the release process of the 32-bit minimal installation media. Or perhaps they have chosen to do it that way for some reason.
Just for the sake of completeness:
If the ISO image also needs to be bootable under UEFI firmware using UEFI native boot process (and not the BIOS compatibility support mechanism) a yet another set of requirements will apply. The partition table (either MBR or GPT) at the beginning of the image would need to contain at least one FAT32 partition marked with a special EFI System Partition type identifier (0xef for MBR partitioning, a specific partition type GUID for GPT partitioning). And that partition would need to have the bootloader as a specifically-named file: for 32-bit x86 architecture, that would be \EFI\BOOT\BOOTIA32.EFI expressed as a Windows-style pathname. For 64-bit x86 architecture, the UEFI boot pathname would be \EFI\BOOT\BOOTX64.EFI.
In practice, some UEFI firmware implementations have somewhat relaxed these requirements. A removable media may be considered as bootable by the UEFI firmware if it contains the appropriately-named bootloader file in the right path on any filesystem that is readable to that particular UEFI firmware implementation. All UEFI firmware implementations are required to understand FAT32 as part of the UEFI specification; but different implementations can add other filesystem types. For example, Apple's UEFI will also understand HFS+ filesystems natively.
