I can't speak on how ETL developer compares to SQL Developer in terms of level. They are 2 different roles from my understanding.
The benefit of branching out is you get to taste a bunch of different sections of SQL Server. The problem with branching out is that the technology is constantly changing. If you become an expert in ETL then change careers over to a database developer, it is a different skillset. It is similar to how senior level DBA's pass off the "easy" tasks to the Jr. DBA's. If you spread yourself thin learning ALL there is to learn about SQL and trying to have a career where you can fit in to any of those positions, you are likely not going to get to the Sr level.
Knowing how to develop ETL and design a database and write stored procedures and such is good knowledge, but my advice is to focus on the particular "part" of SQL you are interested in and build your career around that. Being one-dimensional SHOULDN'T be a bad thing as long as you can say you are an expert in your field. If you relate it over to sports, your quarterback is your quarterback. You don't see the QB playing as an offensive line. They have the area they are the expert in (QB) and they hone their skills and work to make themselves a better QB. Now, you can take that advice TOO far too. If all you are doing is creating tables and nothing else, you've gone too far. A database developer does need to handle multiple tasks. Same thing with an ETL Developer. There are multiple things you need to do and be good at.
It kind of reminds me of being a C# developer AND a SQL Server developer. If I was both and I said I made a WHILE loop, most people would HOPE it was in C# and not in SQL Server. C# loops are frequently needed. SQL Server, loops are rarely needed. But if I am expected to do both, it is possible I got mixed up and put a loop into SQL Server and my performance will tank.
But, that being said, I know some people who are amazing ETL developers. I am not one of them. I am one of the ones that ETL developers hate, but I am also not very good at UI and hate "drag and drop" design interfaces. I prefer getting my hands dirty playing with SDK's and loading DLL's into my code. I don't care how the thing looks as long as it does the job I need it to, so my ETL packages are frequently messy but they work. Do they work well? probably not, but they get the results I need in the timeframe I require, so they are "good enough".
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.