To raczej słabe/nieaktualne podejście i jeśli refaktorować to raczej w drugą stronę (z atrybutów do onClick do addEventListener).
W atrybutach onClick nawet do końca nie można JS pisać (tylko stringi z kodem do odpalenia) i pisanie czegoś na większą skalę w ten sposób było trudne w utrzymaniu.
(zakładając, że ktoś pisze bez frameworka w czystym HTML/JS. Bo np. React ma podobną składnię
Kopiuj
<div onClick={jakasFunkcja}></div>
ale to jednak co innego. Tak się pisze w React, i nie jest to HTML, tylko JSX, który można łączyć ze zwykłym JS. Dlatego w przypadku React jest to prawidłowe i łatwe w utrzymaniu.
Ale w czystym HTML/JS to raczej nie (chyba, że jako niezbyt ładny hak. Ew. jeszcze rozumiem, że dla celów edukacyjnych można by uczyć najpierw tego starszego podejścia z atrybutami onclick i dopiero potem uczyć nowszego addEventListener. Ew. jak ktoś potrzebuje utrzymywać IE8, ale IE8 miało attachEvent zdaje się).
czy tak się pisze prosty front-end w 2018 roku?
nawet w prostym frontendzie użycie addEventListener (albo użycie jQuery, który zapewnia cukier składniowy) jest dość proste...