Maybe others would disagree with me, but I personally wouldn't consider SDL much lower than other similar libraries, especially considering all that it handles (window handling, input, etc). If you jump up much more from it you're kind of venturing into game engine territory.

I'd think your question more feels like whether you should use a fully fleshed out game engine or not, and that would depend on a ton of other variables. You gain a much quicker development speed at the expense of some control and whatever learning process that would apply to you. No one can really give you the right answer there, you kind of have to weigh productivity vs control, vs knowledge*.

*I recognize not everyone wants or needs to know the lower level stuff, or already knows it.

Is your goal to make a game? Use an existing game engine. Is your goal to learn as much as possible? Use SDL and make your own (simple) engine.

It's not quite as simple as that, I'm afraid. But in a lot of cases that's what it boils down to. Ten years ago I, being incredibly ignorant, decided to use SDL and make my own engine. I learned a ton from the process, but I paid dearly because it took a long, long time (several years) until we had a useful and stable engine that could do what we needed it to. My project would be years forward ahead of where it is if we used an existing engine.

Is your goal to make a game? Use an existing game engine. Is your goal to learn as much as possible? Use SDL and make your own (simple) engine.

Does using sdl mean that I'll be creating my own engine? Everybody says that, but you can actually write a simple game(2d, sidescroller) without making an engine. What's the difference between making a game with sdl and making an engine?

Casually speaking, what you're referring to, there really isn't much of a difference. Often people use the term engine to refer to an existing or created framework (such as Unity or GameMaker) that you can use to create a game (Like a car engine, you can build any number of types of cars around it, but the engine itself does much of the work). The phrase "Make games, not engines" generally refers to coding really only what you need for a game, and not to focus on creating a standalone structure. I think it's sometimes misconstrued to mean you should be using pre-existing engines so you can focus on the game aspects of coding. So, in essence, it really means to build your code around what you need.

The term "engine" has a lot of casual uses. For simple games, a fully-featured "game engine" such as Unity, may often be far more than you actually need. In which case, instead using various libraries like SDL, you can create your window, program whatever physics you may need, render sprites, handle whatever game logic, input, and UI functions, and the resulting code would be your "engine." Many of which are easily handled with SDL. You can make things as complex or as simple as your specific game needs.

So, yes, you'd have to make your own engine (using the term loosely here), but that need not be terribly complex and ideally would just include the code to suit your game's needs. For a simple game, SDL would really be handling most of the legwork anyhow (window, input, rendering, etc), and you'd mostly need to just organize what/when you call the SDL functions, and then handle whatever other game logic is needed. But, again to reiterate, you'll want to decide for yourself whether it would be better to go this route, or use a pre-existing engine, by weighing the pros/cons of each approach.

Perhaps take a look at Godot then, if you're interested in the engine route. It's opensource and free, and though I haven't personally used it past some initial toying with it, I hear good things, and its features seem abundant. It uses a python based scripting language, though I believe they include a c++ api as well, if you want to extend or optimize the engine (I don't believe there is support for C though, which you mentioned is your preferred language. But, I could be mistaken).

I think with many engines though, you often need to learn and use their scripting language. I'm unaware offhand of any open-source game engines for C, though I'm certain they're out there.