Is there a CASE LIKE in pl/pgsql?
As was pointed out, you got the CASE syntax wrong.
You also don't need sub-blocks, parameters, multiple distinct UPDATE statements or even the (broken) PL/pgSQL CASE construct. Just an SQL CASE expression in the WHERE clause of the UPDATE:
CREATE OR REPLACE FUNCTION upd_sys_table()
  RETURNS trigger
  LANGUAGE plpgsql AS
$func$
BEGIN
   UPDATE sys_table
   SET    last_modified = EXTRACT(epoch FROM timezone('UTC', now())) * 1000
        , modified_by   = NEW.modified_by
   WHERE  sys_table_name = CASE WHEN TG_TABLE_NAME LIKE 'candy\_%' THEN 'xvw_candy'
                                WHEN TG_TABLE_NAME LIKE 'fruit\_%' THEN 'xvw_fruit'
                           END;
                           
   IF NOT FOUND THEN
      RAISE NOTICE 'No match';
   END IF;

   RETURN NEW;
END
$func$;

Subtle difference: this assumes that rows for 'xvw_candy' and 'xvw_fruit' always exist in sys_table. Else, there is an additional path to NOT FOUND.
Don't confuse SQL CASE with PL/pgSQL CASE. Same keyword, different language, subtly distinct syntax. Among other things, SQL CASE does not require an ELSE branch and defaults to NULL.
If the use case is as simple as your example suggests, you can even just look at the leading 5 characters and use the simpler &quot;searched&quot; CASE like you had in mind:
WHERE  sys_table_name = CASE left(TG_TABLE_NAME, 5)
                           WHEN 'candy' THEN 'xvw_candy'
                           WHEN 'fruit' THEN 'xvw_fruit'
                        END;

Or even just:
WHERE  sys_table_name = 'xvw_' || left(TG_TABLE_NAME, 5) 

See:

Issue with composite type in an UPSERT function

Aside: it's typically better to store an actual timestamptz instead of an epoch as bigint. See:

How to best store a timestamp in PostgreSQL?