il problema è che stai ancora pensando in procedurale :P

dunque: dovendo essere chiamato da un controller sì deve essere chiamato da una pagina web.
questa pagina web però la sigilli permettendo l'accesso solo all'ip locale, quindi nessun utente del tuo sito potrà mai scatenare questa azione.

a livello di dimensioni non hai problemi, perchè la chiamerai in locale, quindi non ci saranno problemi di banda di alcun tipo da dover considerare (ovviamente ti conviene sulla macchina nel file di host dare un alias all'ip e poi settare un virtualhost che rimandi quella chiamata verso la directory root del tuo progetto yii)

perchè un component?
per component intendo più che altro il concetto...
la tua classe non è palesemente un controller, nè un modello... quindi è un componente dell'applicazione.
Parlando di yii in senso stretto potrebbe essere sia un component vero e proprio che una banale estensione.
estendere CComponent?
si, puoi farlo, ma non sei costretto.
che vantaggi comporta?
se è un component è in grado di reagire ad eventi, quindi potresti impostare che se una detereminata chiamata all'interno del sito fa il raise di un evento il component reagisce.

perchè non fare scrivere il parser direttamente sul db? perchè far fare il lavoro al modello?

per una divisione dei compiti.
lo scopo di un parser nel senso stretto è solo ed unicamente uno: parsare un file!

se tu mettessi anche la logica di query nel parser e poi volessi spostare il suddetto parser per usarlo per qualcosa di diverso saresti costretto a modificare il parser per modificare le query. Pertanto la tua applicazione perderebbe di modularità.

Inoltre lasciando al model il compito del salvataggio puoi far gestire a lui ulteriori interazioni.
ad esempio mettiamo che sul db hai dei campi aggiuntivi che indicano tipologie dei dati basati su uno dei dati estratto dal parser.
Usando il model puoi controllare nel beforeSave un determinato campo in arrivo e generare il valore per un altro campo che hai bisogno di riempire nel database, senza dover far generare al parser un campo aggiuntivo basato su una logica che va bene solo ed unicamente per la situazione in cui ti trovi.

faccio un esempio più pratico per spiegarmi meglio:

il file che intendi parsare contiene un elenco di libri, l'autore, ed il numero di pagine

nel tuo db hai deciso che vuoi anche archiviare anche la lunghezza del libro, secondo il parametro che se il libro ha più di 300 pagine è considerato medio, meno di 150 breve, e più di 2000 lungo.

Al parser fai estrarre i normali dati dal file e poi invii al modello, il modello si preoccuperà di fare il controllo sul numero di pagine e generare il valore del campo aggiuntivo.
Questa logica non ha senso di stare nel parser, visto che se poi lo userai altrove non è detto che tu sia interessato ad avere un elaborazione del genere.
Lo scopo del parser è come già detto quello solo di estrarre i dati inseriti nel file, non di elaborarli.

Inoltre facendo gestire l'inserimento sul db al model non hai bisogno di preoccuparti della sintassi delle query (passaggio da db a db) nè di preoccuparti se il campo è nuovo ( ti serve un insert) oppure no (bisogna effettuare un update)

il vantaggio di inserire il tutto nel flusso di lavoro di un controller ti permette inoltre scatenare altri eventi dell'applicazione dopo l'avvenuto parsing.

Mettiamo che stai parsando un elenco di utenti che devi importare nel db.
Questi utenti sono l'elenco dei dipendenti attuali dell'azienda.
All'interno del file, tra i valori da parsare c'è anche lo stipendio mensile.

dopo aver estratto i dati passi il tutto al modello, che contiene anche il campo "ultimo aggiornamento" di tipo date.
il valore di questo campo equivale ovviamente al momento dell'aggiornamento e viene elaborato on the fly dal modello.

Dopo aver effettuato il salvataggio il modello poi si occupa di cancellare/bannare gli utenti non aggiornati, per il fatto che tu sai che quelli non presenti nella lista sono stati licenziati e non lavorano più per l'azienda.
inoltre se lo stipendio è cambiato aggiorni un valore boolean all'interno della tabella che sta ad indicare che lo stipendio è cambiato.

dopo che il modello ha finito il suo lavoro, restituisci al controller l'elenco degli id degli utenti il cui stipendio è cambiato e richiami un altro component che si occupa dell'invio delle mail agli utenti del tuo sistema.

Certo, tutto questo si poteva fare in procedurale, ma dividirlo a pezzi così come stiamo facendo permette di avere oggetti modulari che potrai riutiizzare.
Il parser parserà sempre quel tipo di file, e potrai riusarlo in altre applicazioni oppure per scopi diversi all'interno della stessa.
Farai modifiche al db o aggiungerai campi? nè il parser nè il controller avranno bisogno di saperlo, ti basterà fare le modifiche di caso al modello e tutto funzionerà come sempre.

Il component / estensione che si occupa dell'invio della mail potrai riutilizzarlo in tutti i progetti per i più svariati usi, per il fatto che non sarà legato al resto del flusso di lavoro.

In questo modo il tuo codice è: riusabile e facile da mantenere e testare