Sometimes I want to debug and see all my print statements, but most times not

@Faranta A bit uncertain about what you are asking.
A [print] object will simply print everything that it receives on its inlet to the terminal.
The Pd Terminal Log level you can change in the terminal window...... top left..... but I think you know that.
You can set the Log level at Pd startup with a -d flag........ https://puredata.info/docs/faq/commandline
Which you can use in the standard way by scripting it in a shortcut or a batch file, or if you want it to work when a "pd" patch opens Pd then you can add it to "File" "Preferences" "Startup" ...... down at the bottom of that window "Startup Flags".
David.

Thanks. That's unfortunate. I tried to make my own logger object that encapsulates print but I don't really understand how creation arguments work properly

@Faranta Creation arguments are variables that are interpreted as the object is created (loaded).
When you make your own abstraction you can use them too.
An object [whatever 1 2 x y foo] will have [$1] replaced by 1 and [symbol $3] replaced by x within the abstraction. The $ variables that are replaced must be in an object. $ variables in messages are replaced by atoms of messages coming into those messages.
I had a go at this a while ago..... https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4

[print] has one creation argument that will be printed in the console so a [print this] that receives "2" will print "this 2".
Not what you want. But an abstraction [my-print this that the other] with [print $1] etc. inside?

The log output to the terminal that comes from Pd (some from Pd and some from the tk/tcl code) can be redirected again with command line flags....
-stderr -- send printout to standard error instead of GUI
-nostderr -- send printout to GUI instead of standard error (true by default)
David.

@Faranta You can build your own log system that captures and prints messages sent to it. This abstraction does this by establishing one central [text define log] where all incoming messages of all [logprint] objects are stored. This can of course be refined and expanded: logprint.pd