First a note: the DisplayInformation.AutoRotationPreferences provides roughly the same functionality as the Win32 SetDisplayAutoRotationPreferences function, except that the DisplayInformation one is for UWPs and the Win32 one is for Win32 apps (e.g. with HWNDs). You can't use the UWP API for Win32 apps and vice versa.
The UWP API is only designed to work when the device is in Tablet Mode on Windows 10. Auto-rotation must also be turned on by the user and the device needs to have an accelerometer. In general, your app needs to be the foreground window as well for it to work.
Now that you know all the requirements of the API (which are subject to change, by the way - this is an orientation "preference" after all), is it still not working as intended? The intention is that the user is still in control of the experience.
In some cases, I've seen developers trying to use this API for custom OEM devices running a single app in kiosk mode all the time. The API was designed for normal app scenarios, not for kiosk scenarios. If you have a scenario like this, then ideally you can just describe the hardware configuration you want to drive (like a normal OEM device - e.g. you write the ACPI tables and firmware) and the OS will use the correct orientation. If you're just building a one-off device, you could consider setting the screen rotation using SetDisplayConfig from a Win32 app on startup rather than relying on auto-rotation at all.