keep in mind my experience of source is with and from the perspective of level design, not programming.
short answer:
depends on what you like in an engine.
long answer:
source's most recent sdk is from 2013 and needs old versions of visual studio to even compile, and a havok license will set you back five grand. the tradeoffs that made the engine fantastic for '04 bit it in the ass within a few years as hardware developed away from it; for instance source is very bad at batching draw calls, which probably wasn't as important back then, but is a significant rendering hit as modern GPUs went more into 'drawing a fucktillion tris really fast in one go' (see: the fucking magic Epic are doing with UE5). source is also really, really bad for making large amounts of a level move - lots of stuff is baked into levels during compile. authoring assets for source can also be a pain, as it lacks the niceties of modern engines - i can huck an FBX at unreal or godot just fine, but source wants five-ish precompiled files per model, and the model compiler that spits those out wants the model in SMD and a text file describing how to compile it. CSGO's branch has some nice modern features, but good luck getting your hands on that one's source code. valve stopped bothering with licensing the engine out entirely because their repos are a mess and people kept leaking shit that wasn't sectioned off.
so - it's old, it's clunky, and it takes a lot of effort to pick up even if you're fairly accustomed to development processes in other engines. why do people bother? eh, there's a couple reasons.
let's start on the Hammer Editor - every modern engine out there has either no level design tools, utter dogshit LD tools, or no SDK (cough fucking cough, source 2). godot has nothing. ue4's bsp volumes were vestigial at best, as AAA dev switched to throwing artists and meshes at the problem until it went away. ue5's are apparently alright and kinda powerful, but the tools for actually using them were dogshit until recently. probably serviceable now, but i'm side-eyeing unreal after Recent Industry Turbulence and whatever 'Epic 5.0' is about. don't even fucking talk to me about unity's probuilder. but hammer? holy shit, i wish VMF exporters were better than some tacky blender import scripts. it takes some getting used to, and optimisation within a BSP-based engine is tough to get your head around, but having an actual level design tool is phenomenal. you'll be making your levels out of 'brushes' - convex volumes that the compiler turns into a world mesh. you're set if you move over to source 2 if an sdk ever comes out for that, too, since the tools are comparable, just that hammer 2 is mesh-based from the get-go.
you'll probably be using Hammer++, though, which is a community-made upgrade to the stock version. this segues us nicely into the next bit - source is old and surrounded by weirdly dedicated modders. there's so much community tooling for this engine. every tool i've used to make things for this engine has been community-written, be it a GUI wrapper for the shipped-with-engine commandline tools, or something bigger. VTFEdit for textures. GCFScape for peeking into maps and packed asset files. Crowbar for models. H++ and CompilePal for LD. the Valve Developer Community is an up-to-date wiki that covers every branch. there's a pile of different communities for modding every source game out there, and plenty of technical-minded folks that can help you poke at even the really weird, obscure issues. goddamn!
entityIO and vscript are also very nice entity scripting systems - sdk2013 doesn't have vscript, i think, but you can still throw together a lot of fun things in Hammer with eIO without ever touching a line of code. great for prototyping, great for shipping. tf2's payload gamemode is mostly just existing shit they had for trains and math, with a little bit of extra engine code for making the capture point work right. all the doors in tf2 are also just a generic trigger volume entity rigged up to tell a generic door entity to open. no code needed. it rules.
i'm also very partial to the way source 1 bakes lighting. i truly, honestly prefer the way VRAD does it over every other option available out there. can't tell you why, it's just.. nice lookin.
so, should you use source? ...uh, i don't know, maybe. it's certainly got vastly different strengths than other engines - tools ship with the engine, extremely powerful level editing, beautiful static lighting, robust community support, built-in community server stuff and on-the-fly content download, very moddable... but it struggles with large amounts of dynamic elements, needs a lot of retrofitting, havok's expensive, and wrangling the engine in every different discipline of game development are separate arts that all need to be mastered individually. if you like your all-in-one IDEs, stick to godot or unreal. if you like getting your hands dirty in some proper c++ bullshit, hey, maybe give it a look. if you feel like ripping its guts out to upgrade it a shitload, hey, nothing's stopping you - look what respawn did with it for both titanfalls and apex legends. yeah, that's source 1! i know, right?!
or check out source's distant cousin idtech4. trenchbroom's better than hammer, i hear.
