Hi Aaron,
Your reasoning makes sense in the context of this game. A separate class for checking the user input is a matter of personal preference. As long as you have good arguments, “everything” is fine.
Regarding your collision handler, I like that you defined the strings as constants. That makes your code more maintainable as one will not have to scroll through your code to “update” the tag strings. Editing them at the top of the code is sufficient.
Regarding the LevelHandler method, it is common practice to name one’s method in the manner of “DoSomething”. The name LevelHandler sounds like a class. This indicates that there “should” be a class. Furthermore, one could argue: What does a level have to do with collisions? If the answer is “nothing”, it is good practice to to create separate classes to reflect those independent concepts.
maxLevels is a good idea. However, since you use it only once, you could tidy your class up by making maxLevels a local variable of LevelHandler. Also, SceneManager.sceneCountInBuildSettings is not “expensive”, so you don’t need to assign it in Start(). The same applies to currentSceneIndex as you do not use it anywhere else but in the LevelHandler method.
Acknowledging my limited experience regarding game design and programming, what issues can I have with this approach in the future?
I wasn’t able to spot actual issues. What I wrote above are just ideas how to improve your code in regards to OOP principles. Keep up the good work! 
See also:
- Forum User Guides : How to mark a topic as solved