I'd consider this in the realm of "short-handing", in that these static methods don't necessarily reduce human error or make the logic more concise in any substantial way. They mostly provide "syntactical sugar". They don't make the code more deterministic/predictable (improve safety).
In general short-handing can be a little risky. It can be really useful sometimes and sometimes it can be a real drag that makes you hate the code you wrote a year later.
A lot of it depends on how widely and thoroughly and consistently you adopt these short-hand conventions. It's not so different if you choose to short-hand an identifier with an abbreviated name. It can arguably improve readability and writability to have more compact code (even horizontally), if the convention is applied so thoroughly and consistently enough by you and your entire team that it starts to become something you can immediately recognize at a glance and hardly ever forget. It can hurt all of these desired metrics if it's something exotic and only used occasionally, in which case its introduction just provides the reader another thing to learn and have to constantly keep in memory. Everything is a tightrope balancing act.
So whenever you make these kinds of short-handing design decisions, probably the key thing to make sure is that you apply it widely, thoroughly, and consistently -- make use of them on a daily basis. By doing that, you can reduce intellectual overhead in maintaining the codebase. Failure to do that and a short-hand can actually increase the intellectual overhead.
It is often the tendency of a young and enthusiastic developer with his heart in the right place to want to focus on short-hands, reducing syntax more than clarifying and reducing the logic involved, packing two lines of code into a one-liner, e.g., without actually simplifying the logic in any great way. It's something to kind of balance out over the years as you get more in tune with the actual things that tend to make codebases harder to maintain and the qualities that make code which seemed familiar yesterday seem alien today. The general tendency of a coder, and especially tackling a codebase of scale, is to become confused by his own creations (and I'd add, to fall out of love with his own creations). The probability of that happening reduces the less things you superficially create, and the less you deviate from the idiomatic use of the language. The goal here is familiarity (not less code so much as less code which has a tendency to become unfamiliar).
Performance
Specifically since this question was asked in the context of performance, it is often easier from a performance standpoint to take it easy on these kinds of practices, reduce the layers of function calls. That's not to suggest throwing out the books on procedural programming and start writing monolithic functions that are a nightmare to debug, but anything taken to excess can start to become a bad thing. When you decompose and decompose the codebase into the teeniest functions, and especially in the most performance-critical areas, it can become difficult to optimize not so much because of the cost of a function call (which could effectively be free in a lot of scenarios), but merely because of the code decentralization. A profiling hotspot in such a case might require you to trace into the caller of the caller of the caller of the callee to even get a point where meaningful work is being done worth analyzing and optimizing beyond the most obsessive micro levels.
So my suggestion is to take it easy here, and whatever short-hands you choose to adopt, make sure to adopt them thoroughly, and by your whole team. Otherwise look for ways to reduce the amount of code involved not so much syntactically but more through higher-level logic and imposing constraints on the design in ways that improve things like safety (a less flexible design in exchange for a more predictable design that's harder to misuse, e.g.). It can be useful to kind of develop an appreciation for a slightly more verbose syntax if it isn't any more error-prone and isn't significantly lower-level than the terse alternative, and erring on the side of more code of the sort you have requiring 4 lines to initialize this object rather than 2 might tend to be the safer route as far as longevity and maintainability and even optimization (not performance but easier optimization) is concerned.
If you want to wrap things in a way that makes it easier to apply central optimizations that benefit a large number of things using it, you typically want to establish much higher-level interfaces than ones that merely let you initialize two fields of an object at once.
