When you have a RAID device, even a simple mirrored one, there needs to some metadata about the array stored. At a minimum you need a way to identify the list of devices involved in the array, and in more complicated setups there might be information about stripe size and other tunable parameters.
So where do you store the metadata? There are two choices. The first possibility is to store the disk configuration in memory associated with the card, perhaps with the BIOS configuration or on non-volatile storage on the card itself. The other is to store it on the disk themselves, normally at either at the beginning or the end. The beginning is more robust because then you can still find it trivially even in cases where the disks aren't all the same size, which is normally a supported option (the array just becomes the size of the smallest one). This lets you do a disk-to-disk clone onto a larger unit with a tool like dd when you've got a failing disk, or want to play other tricks to upsize the array; if you know what you're doing it's more flexible. To keep the OS from overwriting this metadata, typically the card will remap the drive so that the first cylinder (or last) is reserved for the card's use rather than being shown to the BIOS.
An advantage of storing the metadata on the disks is that you don't lose any configuration information if there's a power outage long enough for the card's associated battery to run down. It also means that you can put the disks into another system, and as long as you've got the same controller there it can always figure out how the array is configured now matter how you connect the drives. These are important requirements for some applications, particularly when you get into more complicated striping configurations where you have little hope of guessing the right order to reassemble things if you lose that information.
The downside to storing the configuration on disk is that the obvious place to put it, the beginning, is where the operating system has its partition table, boot record, and other important stuff. So if you take a disk with RAID metadata stored there and put that into another system that doesn't have that controller, you won't be able to read it, barring some hairy tricks to skip past the metadata.
Since both use cases, memory vs. disk metadata, have their trade-offs, you can't satisfy everyone with either approach. Your thinking that one or the other is "standard RAID" isn't really accurate, there is no strong standard for RAID metadata. The only one I'm aware of is SNIA RAID Disk Data Format (DDF), which I haven't seen get enough traction among commercial RAID vendors yet to really be considered anything besides a reference standard. That puts the metadata at the physical end of the disk and just deals with the added complexity that adds, so a SNIA DDF compliant RAID1 should work fine standalone. Not all vendors are so capable, and some are using ancient designs that didn't consider this issue and that nobody wants to reengineer now. Now you know the right question ask though: "where's the device metadata stored?", and if it's on disk, "which part of the disk is it physical stored at?".