Why should this be? Don't you read what I write? If you use a file system which uses direct-scsi commands, you can use all capacity the scsi.device recognises as one partition. If you don't have such a file system, all partitions (not only the boot partition) are limited to the first 4 GB of the drive. File corruption only happens in the latter case, if you don't limit partitions to the first 4GB of the drive.
File systems with direct-scsi capability include the old SFS V1.84, FFS V44 (which is the result of the FFSTD64 patch), PFS3 DS and PFS3 AIO.
There is no 8GB limit as such, but scsi.device limits the capacity to what the drive reports. I the drive reports its size according to the ATA specs, the capacity is limited to 8GB. But if the drive does not follow the ATA specs and reports its real size, scsi.device can use all the capacity with direct-scsi commands.
Only if you want to patch scsi.device and then use a file system which does not use direct-scsi but TD64 or NSD, then you need to arrange the boot partition inside the first 4GB and can have other partitions outside.
Another problem can arise if you use FFS (V43 or higher) with big partitions but don't have enough RAM to allow the disk-validator to validate the partitions. Then the affected partition will remain full and write protected although there are no files on it.
I used the Startup-sequence for the "best" example. With the standard Kickstart 3.0/3.1 v40 scsi.device (which is all that's available from a cold boot) no drives of capacity above 8GB can be utilised fully (ie to use their whole capacity) beyond 8GB (even with PFS3DS). That's my experience with my A1200 at least, maybe it's different with CF HDD's, but I don't use CF HDD's.
So the user must then either load a custom Kickstart containing an updated scsi.device (ie v43.x) or load the updated scsi.device as a resident module. The commands that achieve this reside in the Startup-sequence.
Now, if a user has a hard drive that's 40GB for example, and there's just one single large partition (ie, the boot partition 40GB), then as soon as the data writes to the drive reach beyond 8GB then any such writes past that point on the disk will not be readable by the v40 scsi.device. PFS3DS actually locks the drive (I've tried it!).
From cold boot, all we have is the v40 scsi.device - so any modifications to the Startup-sequence or other boot files will not be readable by the Amiga upon cold boot due to the data (Startup-sequence in this case) now being beyond the 8GB point. So basically, the module for loading the essential v43 scsi.device will not be able to load at cold boot due to the Startup-sequence being unreadable. The user then has a serious problem.
Under PFS3, the filenames of such files will be intact due to it's metadata being stored at the beginning of the drive, but file content unreadable under scsi.device v40.
Solution is as my previous post (assuming PFS3DS and internal IDE). If using a boot drive above 8GB, make sure to create a minimum of two partitions, the bootable one must exist within the first 4GB of the drive but can be as large as 8GB in size only (to avoid such problems like I'm trying to describe above).
Or, burn a custom Kickstart ROM with scsi.device v43 or higher.
Of course, if the drive isn't going to be booted from then yes, you can safely create a single large partition of any capacity.