Алгоритм квадратичной сложности. Но сомневаюсь, что он вычисляет именно то, что надо. Если, например, подать на вход список [4, -1, 7, -1, 0, 1, 2, 0, 1, -1, 5], то подпоследовательности [4, -1], [0, 1, 2], [0, 1, 2, 0], [1, 2, 0], [-1, 0, 1, 2, 0, 1], [0, 1, 2, 0, 1, -1], [1, 2, 0, 1, -1] дают в сумме три, и это решение их все не найдёт, потому что ищет только непересекающиеся подпоследовательности, а в формулировке задачи я такого условия не вижу.
Хранение подпоследовательностей не нужно. Лишний расход памяти. Первого и "послепоследнего" индексов хватит.
Если в res добавляются только списки чисел, то условие False in i всегда будет False.
Касательно оформления кода, написано через задницу. Например, использование одной и той же переменной i для семантически абсолютно разных значений, да ещё и разных типов - это ламерство. Вообще, школьная привычка писать "for i in ..." - это заразная болезнь, и от неё нужно лечиться. Название переменной должно отражать её назначение. По сложившейся математической нотации i, j, k - это целочисленные счётчики, а не списки, не строки, не логические значения.
"Решение, вроде, не так уж плохо" - это логика гуманитария, которому в программировании можно доверить только добавлять поля в формочки, посадив ещё 4-х гуманитариев контролировать результат. Зарплату, естественно, делить на пятерых. С практической точки зрения алгоритм характеризуется вычислительной сложностью и расходом памяти, а не расплывчатыми субъективными оценками.