As best I can understand your requirements I think you just need a simple OR condition - but you still need to query the table twice to determine whether a user has an encryption row.

However since you are concerned about performance I have show a way to do it which* appears to only need to access the table a single time.

DECLARE @MYTABLE TABLE (PersonId int, [Encryption] bit, AllowedUser int);

-- 36% of execution plan
INSERT INTO @MYTABLE (PersonId, [Encryption], AllowedUser)
VALUES (123,0,1),(123,0,2),(123,1,3);

DECLARE @AllowedUser int = 3;

-- 12% of execution plan
SELECT *
FROM @MYTABLE mt
WHERE(
    -- Anyone can see unencrypted rows
    [Encryption] = 0
    -- Or if the user has a row with "[Encryption] = 1" then they can see all rows
    OR EXISTS (SELECT 1 FROM @MYTABLE mt1 WHERE [Encryption] = 1 AND AllowedUser = @AllowedUser)
);

-- 52% of execution plan
WITH cte AS (
    SELECT PersonId, [Encryption], AllowedUser
        , MAX(CASE WHEN AllowedUser = @AllowedUser THEN CONVERT(int, [Encryption]) ELSE 0 END) OVER (PARTITION BY AllowedUser) HasEncryption
    FROM @MYTABLE
)
SELECT *
FROM cte
WHERE [Encryption] = 0 OR HasEncryption = 1;

BUT this is not how SQL performance works. SQL is a descriptive language, you are describing the results you want. You are not telling the engine how to obtain those results. It works that out is a very complex manner taking into account indexes, statistics and other magic.

So in this simple case, when I turn on display execution plan, the CTE solution is running much slower than the double table query.

The real lesson here is, don't try and pre-optimise your query, nor assume you know how a given query is going to perform (there are some basic rules of thumb of course). The general rule is, write the query in the most clear, logical manner you can, and if there are then performance issues, performance tune those queries.