Let's compare, using PostgreSQL v16 in a Notebook with Intel i7:
  LTREE module   vs   "VARBIT as pure bit strings".

Sources: https://GIST.github.com/ppKrauss/226fd3fb0dca0a6c6d4f875cb93aa2db

Testing that is the same logic

As the same as SQL Server's IsDescendantOf. At GIST all other @Charlieface examples.

CREATE TABLE treetest.fruit (
    id          bigint  NOT NULL PRIMARY KEY,
    binpath     varbit  NOT NULL,
    charpath    ltree   NOT NULL, 
    info        text
);
--find all apples:
SELECT * FROM treetest.fruit 
-- WHERE  charpath <@ '0'::ltree;
WHERE binpath BETWEEN b'0' AND treetest.MaxBits(b'0');

Benchmark

Comparing performances by psql's \timing command. The function treetest.generate_vbit_series(m) generates all bit strings, from empty to m bits. Using m in {16, 20, 22). This and all other functions in the cited GIST. Example populating a table, see all at GIST:

CREATE TABLE treetest.fruit_vbit (
    id          bigint  NOT NULL PRIMARY KEY,
    binpath     varbit  NOT NULL
);
INSERT INTO treetest.fruit_vbit
 SELECT treetest.vBit_to_hiddenBig(x), x 
 FROM treetest.generate_vbit_series(22) t(x)
; -- 8388606 rows for 22 bits.
  -- 2097150 rows for 20 bits; 131070 rows for 16 bits.

CPU time

Here the main performance test, repeated for each m value (14 to 22).

SELECT COUNT(*) n_t1_r1 FROM treetest.fruit_ltree
WHERE  charpath <@ '1.0'::ltree;

SELECT COUNT(*) n_t1_r2 FROM treetest.fruit_vbit
WHERE binpath BETWEEN b'10' AND treetest.MaxBits(b'10');

------
SELECT COUNT(*) n_t2_r1 FROM treetest.fruit_ltree
WHERE  charpath <@ '1.0.1.1.0.1.0.1.1.0.0.1'::ltree;

SELECT COUNT(*) n_t2_r2 FROM treetest.fruit_vbit
WHERE binpath BETWEEN b'101101011001' AND treetest.MaxBits(b'101101011001');

--- INDEXING:
CREATE INDEX fruit_ltree_idx1 ON treetest.fruit_ltree USING GIST (charpath);
CREATE UNIQUE INDEX fruit_vbit_idx1 ON treetest.fruit_vbit (binpath);

Disc usage

CONCLUSION: vbit indexed is the best, for performance and disc usage. vbit was 4 times faster in large retrieve (1.5 faster in small). The vbit index use 18 times less disc, and the vbit column consumes 4 times less.

SQL Server already has this with the hierarchyid type, many of whose functions are understood by the optimizer and converted into seeks. Postgres seems to have similar functionality using the ltree module, although I have no experience with it.

CREATE TABLE Fruit (
    id hierarchyid PRIMARY KEY,
    info varchar(100) NOT NULL
);

INSERT Fruit (id, info)
VALUES
 ('/0/0/',  'apple "0"'),
 ('/0/0/0/',   'apple "00"'),
 ('/0/0/0/0/',    'apple "000"'),
 ('/0/1/',  'green apple ""'),
 ('/0/1/0/',   'green apple "0"'),
 ('/0/1/1/',   'green apple "1"'),
 ('/1/0/',  'orange "0"'),
 ('/1/0/1/',   'orange "01"');

--find all oranges:
SELECT *
FROM fruit
WHERE id.IsDescendantOf('/1/') = 1;
  
--find all green apples:
SELECT *
FROM fruit
WHERE id.IsDescendantOf('/0/1/') = 1;
  
--find all apples:
SELECT *
FROM fruit
WHERE id.IsDescendantOf('/0/') = 1;
  
--find the parent of the apple 01:
SELECT id.GetAncestor(1) parent
FROM fruit
WHERE id = '/0/1/';
  
--find the parent of the orange 101:
SELECT id.GetAncestor(1) parent
FROM fruit
WHERE id = '/1/0/1/';  

You can see from this fiddle that these are all seeks.

A more correct solution would store the whole tree including the missing root rows. And add a self-referencing foreign key so that an item can only exist if its parent also does.

CREATE TABLE Fruit (
    id hierarchyid PRIMARY KEY,
    info varchar(100) NOT NULL,
    parentId AS (id.GetAncestor(1)) PERSISTED REFERENCES Fruit (id),
    INDEX ix_parentId (parentId, id) INCLUDE (info)
);

INSERT Fruit (id, info)
VALUES
 ('/', 'root'),
 ('/0/', 'all apples'),
 ('/0/0/',  'apple "0"'),
 ('/0/0/0/',   'apple "00"'),
 ('/0/0/0/0/',    'apple "000"'),
 ('/0/1/',  'green apple ""'),
 ('/0/1/0/',   'green apple "0"'),
 ('/0/1/1/',   'green apple "1"'),
 ('/1/',   'all oranges'),
 ('/1/0/',  'orange "0"'),
 ('/1/0/1/',   'orange "01"');