If you are a solo hobbyist game developer who doesn't have much time for it, don't pick a low level framework, and don't build your game from scratch...
TL,DR: If you are a solo hobbyist game developer who doesn't have much time for it, don't pick a low level framework, and don't build your game from scratch, unless your goal is to learn how game engines are built. You have a better chance to finish a game if you build on shoulders of giants. Know what you are building, read books about game design and heavily reduce your scope.
A while ago I have started building a game without any direction, theme or idea what it will evolve into. I called it Project Pivot. It was a good start, I enjoyed learning MonoGame and building the basic mechanics without crutches offered by heavy game engines. However, the progress has slowed, and over last couple of weeks I find it increasingly more difficult to find motivation to continue working on this game. That's why I decided to stop digging this hole, and abandon the project, taking away the valuable lessons I've learned, and sharing them with everyone. I hope you will get something useful out of this rant.
As someone who has a full time job that involves writing code and solving computing problems, moonlighting on a game feels more like a second job than a hobby. Even though I have a burning passion for building games, I can only spend 10-15 hours a week doing this. And that is on a good week, if I'm not completely mentally wasted after work. If I push it, I end up burning out to a point where I am lying half awake every night having blurry dreamish thoughts about code, and my productivity is completely killed both at work and on my game project. Sounds familiar? Turn down your work hours. No matter how much you love game development, it's not worth killing yourself for.
That brings us to the choice of technology. I have spent hundreds of hours learning Unity, and finally ended up choosing MonoGame. Why? Because I am an engineer, and I always prefer to work on lower level and have complete control of the things I'm building. I used to see Unity and most of other game engines as a crutches, or tools for people who don't know how to code, but still want to make games.
Don't start throwing stones at me just yet. I have already realised that this attitude is dumb, arrogant and wrong on so many levels. A massive misconception I've always had is that making games is mostly a software development activity. It's not. Not even close. It may have been true 20 years ago, but at those times people spent years writing low level code building simple games that can be replicated today in weeks, if not days.
For someone who only has 10-15 hours a week for building games, choosing to go low level is a straight suicide. You will have to (poorly) reimplement things that an engine already has built in and ready to use. This is great for learning, no doubts, but what is your end goal? To learn how to build your own poor man's game engine, or to build a complete, finished game?
I really enjoy writing lower level code. It makes me feel like a pig rolling around in the mud. Time flies by quickly, but when I step back to look at what I have after pouring a hundred hours in it, reality hits hard. It's too slow, and at this pace I will not finish the game in years.
Time to swallow the pride and embrace the crutch. I want to build and finish games, not fuck around implementing things that already have solid implementations provided for you. Hello again, Unity. I'm sorry I've been unfaithful.
On a side note, if you are working as a full time gamedev in a team with talented, experienced software developers, frameworks like MonoGame, SDL, SFML and alike could indeed be a better choice than Unity, and games like Starbound are solid proof. It all depends on what you do and what resources or constraints you have.
When I started Project Pivot, I thought "I'll just start playing around with tech side and mechanics, and the rest will unfold itself in the process". The hell it will. Read some books about game design before you start building a game. And to be clear with terms, game design is not "visual design", it's designing the whole game, all aspects of it. It is really, really difficult to design a game that someone will want to play, and after you realise that the concept you have spent so much time on is so dull that even you don't want to play it, you can kiss your motivation goodbye.
There are enough bad games out there already, to a point of over-saturation, but they probably are necessary part of learning process for the developers. But you have a chance to reduce the amount of bad games out there, equipped with knowledge provided by books. That's what I'm reading right now, and I will not start making any new game before I finish it: The Art of Game Design: A Book of Lenses. It's a real eye-opener.
You've all heard it so many times. Reduce scope! Reduce scope! I've heard it so many times, yet I still managed to start building a fucking crafting system in my prototype... Optimism is a great trait, but dumb optimism doesn't lead anywhere. Know your time and skill constraints before you start adding something.
The real challenge is to come up with a game that is fun to play yet has minimal set of mechanics that aren't too time consuming or complex to implement. Better have a small simple thing polished well, than a half-assed implementation of something really sophisticated. Don't think that using Perlin noise to generate terrain equates to having awesome procedurally generated levels. Not even close.
Don't get disappointed when you fail. If you find yourself in a hole, stop digging. Fail fast, and bring your increasingly stronger knowledge to the next project. As it's written in "The Art of Game Design": Your first ten games will suck - so get them out of the way fast.