Can a Text attribute can be used in transformation rules

You could do this, but it's a bit of work. It would be much simpler just to do it in transformation rules.
However, if I assume that you have Cost Center dimension that already has Text attributes for other purposes (e.g. finance calculations, reporting, allocation rules, seeding rules) and not just for Transformation rules, and you are really sure that the Text attributes is a good place for this, then yes you could use Text attributes in the target dimension as a sort of 'mapping table' which could be used by Transformation rules.
The way to do it, it get the list of members and their Text attributes into a Dictionary object, and store this as a Globals object, so you have a fast lookup that persists in-memory for the duration of the transformation process.

The code snippet below will build a list in memory 
<Member Name A>,<Text1 Value>
<Member Name B>,<Text1 Value>
<Member Name C>,<Text1 Value>
and so on..

Assumptions for this snippet:
Assumes Cost Center is on UD1 dimension.
Many cost Center members could have the same Text property (many CC to one PC, or one-to-one).
Assumes the Text property is the valid profit center name.
Assumes the source UD column in stage is the cost center name (requires no pre-mapping).
Example in screen capture below is a snippet only, for inspiration purposes only, and not a complete solution.

Hope this provides some help
Regards
Chris

Chris is spot on.  It would be much simpler to do this in the transformation rules.  This also has a performance impact if you used the Text attributes.  The Validate process does the transformation in the Stage engine.  The Validation process is an extremely memory intensive process.  It is processing pages and pages of validation rules in memory cache.  So for optimal performance, the process will consume as much memory that it is available at the time.  Chris's solution is viable and will work.  However, as Chris mentioned, your crossing the Stage engine to the Finance engine to collect 1 to many Dimension members and their Text attribute values to store in memory as a lookup consuming memory resources.  This lookup collection will take up a significant amount of memory to process and store during the Validation process.  In addition, Conditional mapping or mapping done within complex expressions/scripts have the highest processing costs.  This type of mapping requires to return a recordset with all dimension fields back to the application server in order to perform the conditional mapping process. This causes a lot of data transfer and memory utilization. In many cases, this will slow down the Validation process.  So this is also a performance design decision as well.  Something to consider.