Sort of. By default, most SELinux systems have users logged in as `unconfined_u`, which as the name implies receives nearly no confinement.

Any application that doesn't have a specific policy written for it will either inherit the domain that spawned it (in this case, `unconfined_u:unconfined_r:unconfined_t:s0:c0.c1023`) or receive some default domain (e.g., `system_u:system_r:unconfined_service_t` for systemd services, `initrc_t` for init daemons, etc.)

Because of this, most applications will end up inheriting the user's domain, which again is `unconfined_t` by default under the targeted policy.

Lots of common applications have policies so that they transition to their own domain and then execute under customized policy, but it's less common for user applications (and especially user applications that are not system tools) than for daemons so it's not generally safe to assume you're protected by selinux when going about typical user tasks.

However, writing SELinux policy isn't that hard (although it's a bit harder than just `audit2allow` to do it well) and it's a perfectly reasonable project for an afternoon to write a policy for an unconfined application you use, if you're willing to spend some time up front learning about SELinux policy language.