Hm jein... eher nicht.
Normalerweise ist es so: Alles in die Main-Loop und in die Interrupts so kurz wie nur irgendwie möglich.
Dauert die ISR nämlich so lange, dass in deren Abarbeitung der Interrupt bereits ein weiteres Mal aufgerufen wird, dann kanns Probleme geben.
Also eine Timer-ISR, die im Sekundentakt aufgerufen wird und dort die Anweisung "WAIT 2" ausführt wird etwas Stress machen.

Will man auf ein Ereignis reagieren, kann man entweder den ganzen Code direkt in der ISR abarbeiten, oder man setzt nur ein Flag, das dann in der Main-Loop bei jedem Durchlauf geprüft und der Code dann entsprechend abgearbeitet wird.
(If FlagXYZ = 1 Then...)

Wie man das macht, kommt halt drauf an, wie "wichtig" das Ereignis ist. Muss z.B. sofort drauf reagiert werden (Not-Aus, ankommende Daten), ist es sicher sinnvoll, den Code direkt in der ISR zu bearbeiten.

Will man aber z.B. nur den Status eines Geräts erfassen (z.B. SD-Kartenslot, Signal "Karte steckt"), reicht es, in der ISR ein Flag zu setzen.
Wobei ein Interrupt hier aber schon fast wieder übertrieben scheint, da normales "Polling" auch reicht.

Interrupts sind auch sinnvoll, um kurze Pinänderungen "aufzuspüren";
Würde man einen Pin nur in der Main-Loop pollen, könnte der sich ändern, ohne dass das Programm was mitbekommt.
Mit dem Interrupt wird die Änderung registriert => Flag setzen und schon hat man die Änderung.

So wie ich das Programm mit der Tastatur verstanden hab, muss die Tastatur unmittelbar nach Auftreten eines Clock-Pulses ausgelesen werden, da die Daten sonst verloren gehen; also warten, bis in der Main-Loop irgendwann mal das Flag überprüft wird, geht nicht.
Das Auswerten, also WELCHE Taste da nun gekommen ist, könnte man dann durchaus in die Main-Loop auslagern.